Cloudanix VulnDB

CVE-2026-98616

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in a Linux network driver can make the computer crash when certain power or hardware error conditions occur.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in fbnic driver where num_napi count is not reset after napi vectors and IRQs are freed during failed PCIe recovery or partial resume open paths, allowing later dereference of freed structures on unbind.

Why it matters to the business

Kernel crashes and potential denial of service on systems using the affected network hardware; low EPSS and absence from KEV indicate limited immediate exploitation risk five days after publication.

How an attack unfolds

An attacker with local or privileged access induces a PCIe error recovery failure or partial __fbnic_open failure on resume to leave num_napi pointing at freed vectors, then triggers driver unbind to cause NULL dereference in fbnic_dbg_down.

How to fix it

Update to a Linux kernel containing the fix that clears num_napi on vector free in suspend teardown and resume open failure paths; apply available stable updates as they are released.

How to confirm the fix worked

Inspect fbnic driver source for num_napi = 0 assignments in fbnic_pm_suspend and error unwind paths; verify no NULL dereference occurs during simulated error recovery and unbind sequences.

Typical attack path

  1. Trigger PCIe error recovery or suspend/resume failure path
  2. Leave datapath torn down without rebuilding num_napi
  3. Initiate driver remove or unbind to enter fbnic_down
  4. Dereference freed napi vectors causing kernel oops

How to detect it

Search kernel logs and crash dumps for NULL pointer dereference involving fbnic_dbg_down; review dmesg and journalctl for entries during driver unload after suspend or error recovery events.

  • BUG: kernel NULL pointer dereference, address: 0000000000000210
  • RIP: fbnic_dbg_down+0x28
  • fbnic_down -> fbnic_dbg_down

What your security team should do

  • Prioritize kernel updates for systems using fbnic hardware
  • Monitor kernel logs for fbnic-related oops messages
  • Restrict unprivileged access to hardware reset or error injection interfaces

The record

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 packages

Ecosystem Package Introduced Fixed