CVE-2026-98561 in Linux
Summary
by MITRE • 10/18/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in the Linux kernel network processor firmware driver, specifically within the nfp_net_ipsec_rx function, represents a critical race condition involving concurrent access to shared data structures during IPsec packet processing. This flaw arises from an improper locking strategy where the XArray lock is released before securing a reference count on the xfrm_state object retrieved from that array. In high-throughput network environments, this timing gap allows for a window of opportunity where another thread or interrupt handler can modify the state of the data structure while it is being accessed by the RX path. The core technical issue lies in the sequence of operations: the driver looks up an entry in the XArray to find the associated IPsec security association state and then attempts to increment its reference count. However, because the lock protecting the array is dropped before this increment occurs, a concurrent deletion operation can remove the entry from the array and subsequently drop the final reference to that object, effectively freeing or invalidating it while the RX path still holds a pointer to it.
This race condition leads to a use-after-free scenario where the receive processing logic attempts to operate on an xfrm_state structure that has already been queued for destruction or deallocation by the delete path. Specifically, after the entry is erased from the XArray and its reference count drops to zero, the garbage collector may eventually reclaim the memory associated with that state object. If the RX thread proceeds to increment a refcount on this now-invalidated pointer, it results in undefined behavior, potentially leading to kernel panics, data corruption, or system instability. The asynchronous nature of firmware invalidation exacerbates this issue because the delete path does not wait for pending receive processing to complete before proceeding with cleanup operations. This lack of synchronization means that hardware-level packet processing can continue against software-managed state structures that are in the process of being torn down by the kernel's networking stack.
From a security and operational impact perspective, this vulnerability allows for local denial-of-service attacks if an attacker can trigger rapid creation and deletion of IPsec tunnels or states to exploit the race window. While remote code execution is less likely given the nature of refcount manipulation errors which typically result in crashes rather than arbitrary write primitives, the stability implications are severe for production network infrastructure relying on hardware-accelerated IPsec offloading. The vulnerability aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition), as it involves multiple execution paths accessing shared state without proper mutual exclusion during critical sections of reference counting and object lifecycle management. Furthermore, the exploitation vector relates to ATT&CK technique T1499, Endpoint Denial of Service, specifically through resource exhaustion or instability induced by kernel-level crashes triggered via network traffic patterns that stress the IPsec processing pipeline.
The resolution involves restructuring the locking logic within nfp_net_ipsec_rx to ensure atomicity between lookup and reference acquisition. By taking the xfrm_state reference while still holding the XArray lock, the driver prevents any concurrent deletion operations from erasing the entry or dropping references during this critical interval. This ensures that if an object is found in the array, its lifetime is extended until the RX processing completes, preventing access to freed memory. Additionally, addressing the asynchronous firmware invalidation requires careful coordination between the delete path and pending receive queues to ensure no packets are processed against stale state objects. Mitigation strategies for administrators include applying kernel updates that contain this patch as soon as they become available in their respective distribution channels. For environments where immediate patching is not feasible, limiting the rate of IPsec tunnel creation or deletion can reduce the probability window for exploitation, although complete mitigation requires the code-level fix to eliminate the race condition entirely.