Live › vulnerability › CVE-2026-98561
Go to dashboardIn the Linux kernel's nfp Netronome network driver, the IPsec receive path could take a reference to an xfrm_state after it had been queued for destruction, a refcount race. The sources do not state what an attacker gets at worst.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with the nfp driver (Netronome/Corigine SmartNIC hardware) and IPsec offload enabled are the ones this race applies to. Hosts without that NIC or without IPsec offload are unlikely to be exposed. The sources do not say more.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-98561")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.