Cloudanix VulnDB

CVE-2026-98561

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A locking mistake in a Linux network driver can cause computers to crash when handling secure network connections.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Privilege Gain
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in the nfp driver where nfp_net_ipsec_rx drops the XArray lock before acquiring a reference on an xfrm_state, allowing xa_erase and final refcount drop to occur in the window before the reference is taken, followed by an invalid increment on a state queued for destruction.

Why it matters to the business

Kernel instability or crashes on systems using the nfp network driver with IPsec, resulting in unexpected downtime and service disruption for affected hosts.

How an attack unfolds

An attacker with local or network access that can trigger concurrent IPsec state creation/deletion and RX processing paths forces the driver into the unprotected window between XArray lookup and reference acquisition, leading to use of a freed xfrm_state.

How to fix it

Apply the upstream fix that acquires the xfrm_state reference while still holding the XArray lock; rebuild and deploy the patched kernel on all affected hosts.

How to confirm the fix worked

Inspect nfp_net_ipsec_rx source to confirm the reference acquisition occurs before XArray lock release; test under concurrent RX and state deletion workloads for absence of refcount warnings or crashes.

Typical attack path

  1. Establish IPsec flows that populate xfrm_state entries in the nfp driver
  2. Trigger concurrent deletion of an xfrm_state while RX processing is active
  3. Exploit the interval after lock release but before refcount acquisition
  4. Cause the driver to reference a state already queued for RCU reclamation

How to detect it

Search kernel logs for oops, warnings, or stack traces mentioning nfp_net_ipsec_rx, xfrm_state, or refcount errors occurring shortly after IPsec state deletion events.

What your security team should do

  • Prioritize kernel update on any host using the nfp driver with IPsec
  • Add kernel oops and refcount warning monitoring for nfp-related symbols
  • Re-test IPsec performance and stability after patching

The record

In the Linux kernel, the following vulnerability has been resolved: nfp: hold IPsec RX state under the XArray lock nfp_net_ipsec_rx() drops the XArray lock before taking a reference to the xfrm_state it found. The delete path can erase the entry and drop the last state reference in that interval. RX can then try to increment a zero refcount after the state has been queued for destruction. The driver queues firmware invalidation asynchronously; the delete path does not wait for the command to complete or drain pending RX processing. The XFRM garbage collector waits for an RCU grace period before freeing the state. That delays reclamation but does not make acquiring a reference from zero valid. Take the xfrm_state reference before releasing the XArray lock so xa_erase() cannot run between lookup and reference acquisition.

Affected packages

Ecosystem Package Introduced Fixed