CVE-2026-98616: eth: fbnic: reset num_napi when the napi vectors are freed
In the Linux kernel, the following vulnerability has been resolved:
eth: fbnic: reset numnapi when the napi vectors are freed
fbn->numnapi is the count of live napi vectors, each of which owns an IRQ. The PM path had freed them without clearing the count. fbnicpmsuspend() tears the datapath down via ndostop() and frees the IRQs, but leaves netifrunning() true so resume knows to re-open. Resume rebuilds the datapath in fbnicpmresume() and fbnicresetqueues() sets numnapi and fbnicopen() re-allocates the vectors.
When the datapath is torn down but never rebuilt, numnapi is left pointing at freed vectors under 2 different scenarios: - a PCIe error recovery that fails (fbnicerrslotreset() -> fbnicpmresume() returns an error -> PCIERSRESULTDISCONNECT), so .resume never runs; or - an fbnicopen() that fails partway on resume and unwinds, freeing the vectors after fbnicresetqueues() has already set numnapi.
The netdev is then running with numnapi > 0 but napi[] freed, and the eventual remove/unbind close re-enters fbnicdown() -> fbnicdbgdown() and dereferences the freed vectors: BUG: kernel NULL pointer dereference, address: 0000000000000210 RIP: fbnicdbgdown+0x28
Clear numnapi when the vectors are freed: in the suspend teardown (a good resume re-establishes it before fbnicopen()) and on the resume open failure. A redundant ndostop() then walks an empty napi[]. The normal ndostop() down/up cycle is untouched and keeps numnapi for the next ndoopen().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Clear/reset num_napi when the NAPI vectors are freed during suspend teardown, before any subsequent ndo_stop() or open/resume path can access them.
Linux kernel fbnic driver num_napi = 0
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel fbnic network driver are exposed when the driver’s datapath is torn down and its NAPI/IRQ vectors are freed without clearing num_napi. The affected state can arise during power-management resume or PCIe error recovery.
What conditions lead to the invalid state?
The issue occurs if PCIe slot recovery fails before the normal resume path runs, or if reopening the device during resume fails partway through and unwinds after num_napi has been set. In both cases, num_napi can remain nonzero after the NAPI vectors have been freed.
How might an affected system fail?
A later device remove, unbind, or close operation can re-enter the driver shutdown path and dereference the freed vectors. The reported result is a kernel NULL pointer dereference in the fbnic driver.
How can administrators identify a potentially affected device state?
The problematic state is a running network device with num_napi greater than zero while its napi array has already been freed. Kernel crash output may show a NULL pointer dereference during the fbnic shutdown/debug-down path after a failed resume or PCIe recovery.