CVE-2026-98229 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
xfrm: save input state data before secpath resets
xfrm_input() stores the current xfrm_state in the skb secpath while it continues receive-side processing. Some input paths can reset that secpath before xfrm_input() has finished dereferencing the state.
Receive callback users such as VTI and XFRM interfaces can reset the secpath. The VTI receive path does so before checking whether the packet crosses network namespaces, while the XFRM interface path does so only for cross-network-namespace packets. The XFRM_MAX_DEPTH error path can also reset the secpath before the final drop callback reports the current state's protocol.
If secpath_reset() drops the last state reference while the state is concurrently deleted, xfrm_input() can still dereference the freed state when selecting transport_finish() or reporting the drop callback protocol.
Save the state protocol on the stack while the state is still valid, and use the already saved address family for transport_finish(). A larval XFRM_STATE_ACQ state has no type, so retain nexthdr as its protocol. This preserves the existing drop-path fallback while avoiding the post-reset state dereferences without adding an extra state reference to every received packet.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in the Linux kernel's IPsec implementation involves a use-after-free condition within the xfrm_input function, which is responsible for processing incoming encapsulated packets. This flaw arises from a race condition between the dereferencing of security association state objects and their potential deallocation triggered by secpath resets. Specifically, the xfrm_input routine stores references to current xfrm_state structures in the socket buffer's security path during receive-side processing. However, certain input paths are capable of resetting this security path before the initial function has completed its necessary dereferencing operations. This temporal gap creates a window where previously valid memory pointers may become invalid if the referenced state is concurrently deleted or released by other parts of the kernel network stack.
The operational trigger for this vulnerability often involves receive callback users such as Virtual Tunnel Interface and XFRM interfaces, which have specific behaviors regarding security path management. The VTI receive path resets the secpath before verifying whether a packet crosses network namespace boundaries, while the XFRM interface path performs this reset only for cross-namespace packets. Additionally, error handling paths within xfrm_input, particularly those leading to an XFRM_MAX_DEPTH error, may also invoke secpath_reset prior to reporting the protocol of the current state in drop callbacks. When a secpath_reset operation drops the last reference count on a state object while that same object is being concurrently deleted by another thread or process context, the kernel retains stale pointers to freed memory. Subsequent attempts to access this memory during transport_finish selection or when invoking drop callback protocols result in undefined behavior, potentially leading to kernel crashes or arbitrary code execution if an attacker can control the contents of the freed memory region through carefully crafted network traffic.
From a technical classification perspective, this vulnerability aligns with CWE-416, Use After Free, as it involves accessing memory after it has been freed due to improper reference counting and synchronization mechanisms. In terms of adversary tactics, this flaw could be leveraged within the ATT&CK framework under techniques related to privilege escalation or defense evasion, specifically by exploiting kernel memory corruption to gain elevated privileges or disrupt system stability. The impact ranges from denial of service through kernel panics to potential remote code execution depending on the specific exploitation context and available heap grooming opportunities.
To mitigate this vulnerability, developers have implemented a fix that involves saving critical state data onto the stack before any secpath reset operations occur. By preserving the protocol information in local variables while the xfrm_state remains valid, the system ensures that subsequent functions like transport_finish can utilize these saved values rather than dereferencing potentially freed pointers. For larval states where type information is unavailable, the next header value is retained as a fallback mechanism for protocol identification. This approach maintains existing error handling behaviors without introducing additional reference counting overhead for every received packet, thereby resolving the race condition while preserving performance characteristics and system stability.