eth: fbnic: reset num_napi when the napi vectors are freed

Overview

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:

• 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

• Linux >= bc6107771bb4be3009168cfda24d22131c026fe8 < c5b5aee41b9f5ed0743344be1c7b544555fa3cb9
• Linux >= bc6107771bb4be3009168cfda24d22131c026fe8 < 4f4b767ffea7653a00904383908536e754f8ef5b
• Linux >= bc6107771bb4be3009168cfda24d22131c026fe8 < 4bcc4a92c603fe7f062cea22e20da2e0ad6b12c3
• Linux 6.11

Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.