CVE-2026-98616

In 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:

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().