---
id: "CVE-2026-98616"
kind: "vulnerability"
aliases: ["CVE-2026-98616"]
title: "Linux kernel fbnic driver: NULL pointer crash after failed PCIe recovery or resume"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["fbnic", "linux-kernel", "package", "servers"]
not_affected_if: ["no-fbnic-hardware"]
published_at: "2026-10-18T16:17:14+00:00"
first_seen_at: "2026-10-23T21:57:16+00:00"
updated_at: "2026-10-25T05:21:20+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98616", "first_seen_at": "2026-10-23T21:57:16+00:00"}]
---

# Linux kernel fbnic driver: NULL pointer crash after failed PCIe recovery or resume

The fbnic network driver in the Linux kernel keeps a count of napi vectors after freeing them during suspend or a failed resume, so a later close dereferences freed memory. The sources describe a kernel NULL pointer dereference in fbnic_dbg_down, which crashes the machine rather than granting an attacker access.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `uname -r` and check whether the kernel includes the fbnic num_napi fix in its stable release notes
- Run `lspci -k | grep -A3 -i fbnic` to see if the fbnic driver is bound to a device

## Fix

- Update the Linux kernel to a release that includes the upstream fbnic fix (the sources do not name a version: unknown)
- Reboot after updating so the patched module loads

## Timeline

- 2026-10-23T21:57:16+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98616

## From the sources

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

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_