fbnic: close fw_log race between users and teardown
In the Linux kernel, the following vulnerability has been resolved: fbnic: close fw_log race between users and teardown Fixes a theoretical race on fw_log between the teardown path and fw_log write functions. fw_log is written inside fbnic_fw_log_write() and can be reached from the mailbox handler fbnic_fw_msix_intr(), but fw_log is freed before IRQ/MBX teardown during cleanup, resulting in a potential data race of dereferencing a freed/null variable. Possible Interleaving Scenario: CPU0: fbnic_fw_msix_intr() // Entry fbnic_fw_log_write() if (fbnic_fw_log_ready()) // true ... preempt ... CPU1: fbnic_remove() // Entry fbnic_fw_log_free() vfree(log->data_start); log->data_start = NULL; CPU0: continues, walks log->entries or writes to log->data_start The initialization also has an incorrect order problem, as the fw_log is currently allocated after MBX setup during initialization. Fix the problems by adjusting the synchronization order to put initialization in place before the mailbox is enabled, and not cleared until after the mailbox has been disabled.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.18.14, 6.19.4
- CVEs
- CVE-2026-45977
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 8 Nov 2026, 00:40 UTC · Revision 1
Source evidence
fbnic: close fw_log race between users and teardown
core-osv · Original sourcePublished 27 May 2026, 12:18 UTC
In the Linux kernel, the following vulnerability has been resolved: fbnic: close fw_log race between users and teardown Fixes a theoretical race on fw_log between the teardown path and fw_log write functions. fw_log is written inside fbnic_fw_log_write() and can be reached from the mailbox handler fbnic_fw_msix_intr(), but fw_log is freed before IRQ/MBX teardown during cleanup, resulting in a potential data race of dereferencing a freed/null variable. Possible Interleaving Scenario: CPU0: fbnic_fw_msix_intr() // Entry fbnic_fw_log_write() if (fbnic_fw_log_ready()) // true ... preempt ... CPU1: fbnic_remove() // Entry fbnic_fw_log_free() vfree(log->data_start); log->data_start = NULL; CPU0: continues, walks log->entries or writes to log->data_start The initialization also has an incorrect order problem, as the fw_log is currently allocated after MBX setup during initialization. Fix the problems by adjusting the synchronization order to put initialization in place before the mailbox is enabled, and not cleared until after the mailbox has been disabled.
osv:CVE-2026-45977
Kernel
Fixed versions: 6.18.14, 6.19.4
Complete source record
{
"id": "1b741c3e7ab918c11cc352324f4d4ea0a3fb3da0de3e21d16c219e7f97ee4b89",
"url": "https://osv.dev/vulnerability/CVE-2026-45977",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "fbnic: close fw_log race between users and teardown",
"summary": "In the Linux kernel, the following vulnerability has been resolved: fbnic: close fw_log race between users and teardown Fixes a theoretical race on fw_log between the teardown path and fw_log write functions. fw_log is written inside fbnic_fw_log_write() and can be reached from the mailbox handler fbnic_fw_msix_intr(), but fw_log is freed before IRQ/MBX teardown during cleanup, resulting in a potential data race of dereferencing a freed/null variable. Possible Interleaving Scenario: CPU0: fbnic_fw_msix_intr() // Entry fbnic_fw_log_write() if (fbnic_fw_log_ready()) // true ... preempt ... CPU1: fbnic_remove() // Entry fbnic_fw_log_free() vfree(log->data_start); log->data_start = NULL; CPU0: continues, walks log->entries or writes to log->data_start The initialization also has an incorrect order problem, as the fw_log is currently allocated after MBX setup during initialization. Fix the problems by adjusting the synchronization order to put initialization in place before the mailbox is enabled, and not cleared until after the mailbox has been disabled.",
"evidence": "osv:CVE-2026-45977",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.18.14",
"evidence": "/affected/1/ranges"
},
{
"value": "6.19.4",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-45977",
"aliases": [
"CVE-2026-45977"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "ecc53b1b46c892d2e3cf3cf4393b6d219dc4ae3f"
},
{
"fixed": "223cfef4812bdfa5ac5c1aa761cdba03cfe2c9cd"
},
{
"fixed": "5f10ab3643c58a22fbaee92c4701b00fcb4a465d"
},
{
"fixed": "ee5492fd88cfc079c19fbeac78e9e53b7f6c04f3"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-45977.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.17.0"
},
{
"fixed": "6.18.14"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "6.19.4"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-45977.json"
}
}
],
"modified": "2026-10-28T02:30:52.643412007Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/223cfef4812bdfa5ac5c1aa761cdba03cfe2c9cd",
"https://git.kernel.org/stable/c/5f10ab3643c58a22fbaee92c4701b00fcb4a465d",
"https://git.kernel.org/stable/c/ee5492fd88cfc079c19fbeac78e9e53b7f6c04f3",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/45xxx/CVE-2026-45977.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-45977",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/45xxx/CVE-2026-45977.json"
}
},
"related_cves": [
{
"value": "CVE-2026-45977",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 521044,
"published_at": "2026-05-27T12:18:35.858+00:00"
}