GHSA-MR3Q-WFMX-4W6M
Vulnerability from github – Published: 2026-10-18 18:31 – Updated: 2026-10-18 18:31In the Linux kernel, the following vulnerability has been resolved:
eth: fbnic: reset num_napi when the napi vectors are freed
fbn->num_napi is the count of live napi vectors, each of which owns an IRQ. The PM path had freed them without clearing the count. fbnic_pm_suspend() tears the datapath down via ndo_stop() and frees the IRQs, but leaves netif_running() true so resume knows to re-open. Resume rebuilds the datapath in __fbnic_pm_resume() and fbnic_reset_queues() sets num_napi and __fbnic_open() re-allocates the vectors.
When the datapath is torn down but never rebuilt, num_napi is left pointing at freed vectors under 2 different scenarios: - a PCIe error recovery that fails (fbnic_err_slot_reset() -> __fbnic_pm_resume() returns an error -> PCI_ERS_RESULT_DISCONNECT), so .resume never runs; or - an __fbnic_open() that fails partway on resume and unwinds, freeing the vectors after fbnic_reset_queues() has already set num_napi.
The netdev is then running with num_napi > 0 but napi[] freed, and the eventual remove/unbind close re-enters fbnic_down() -> fbnic_dbg_down() and dereferences the freed vectors: BUG: kernel NULL pointer dereference, address: 0000000000000210 RIP: fbnic_dbg_down+0x28
Clear num_napi when the vectors are freed: in the suspend teardown (a good resume re-establishes it before __fbnic_open()) and on the resume open failure. A redundant ndo_stop() then walks an empty napi[]. The normal ndo_stop() down/up cycle is untouched and keeps num_napi for the next ndo_open().
{
"affected": [],
"aliases": [
"CVE-2026-98616"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-18T16:17:14Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\neth: fbnic: reset num_napi when the napi vectors are freed\n\nfbn-\u003enum_napi is the count of live napi vectors, each of which owns an\nIRQ. The PM path had freed them without clearing the count.\nfbnic_pm_suspend() tears the datapath down via ndo_stop() and frees the\nIRQs, but leaves netif_running() true so resume knows to re-open. Resume\nrebuilds the datapath in __fbnic_pm_resume() and fbnic_reset_queues() sets\nnum_napi and __fbnic_open() re-allocates the vectors.\n\nWhen the datapath is torn down but never rebuilt, num_napi is left\npointing at freed vectors under 2 different scenarios:\n - a PCIe error recovery that fails (fbnic_err_slot_reset() -\u003e\n __fbnic_pm_resume() returns an error -\u003e PCI_ERS_RESULT_DISCONNECT), so\n .resume never runs; or\n - an __fbnic_open() that fails partway on resume and unwinds, freeing\n the vectors after fbnic_reset_queues() has already set num_napi.\n\nThe netdev is then running with num_napi \u003e 0 but napi[] freed, and the\neventual remove/unbind close re-enters fbnic_down() -\u003e fbnic_dbg_down()\nand dereferences the freed vectors:\n BUG: kernel NULL pointer dereference, address: 0000000000000210\n RIP: fbnic_dbg_down+0x28\n\nClear num_napi when the vectors are freed: in the suspend teardown (a\ngood resume re-establishes it before __fbnic_open()) and on the resume\nopen failure. A redundant ndo_stop() then walks an empty napi[]. The\nnormal ndo_stop() down/up cycle is untouched and keeps num_napi for the\nnext ndo_open().",
"id": "GHSA-mr3q-wfmx-4w6m",
"modified": "2026-10-18T18:31:56Z",
"published": "2026-10-18T18:31:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98616"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4bcc4a92c603fe7f062cea22e20da2e0ad6b12c3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4f4b767ffea7653a00904383908536e754f8ef5b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5b5aee41b9f5ed0743344be1c7b544555fa3cb9"
}
],
"schema_version": "1.4.0",
"severity": []
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.