CVE-2026-98370 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
xfrm: fix compat ALLOCSPI request use-after-free
xfrm_state_netlink() builds the ALLOCSPI response with dump_one_state(), which already calls alloc_compat() with the response skb and header.
xfrm_alloc_userspi() then calls alloc_compat() again, but passes the original request skb and its header. For a compat request, the translator therefore interprets the 228-byte compat xfrm_userspi_info as the 232-byte native layout and reads four bytes past the declared payload. It also publishes the translated child through the request's frag_list.
A multicast clone of the request shares skb_shared_info and can observe that child. xfrm_user_rcv_msg() frees it after the request handler returns, racing a compat receiver which may still be copying from it and resulting in a use-after-free.
Remove the redundant conversion. The response keeps its correct compat translation from dump_one_state(), and no child is attached to the inbound request.
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 as CVE-2024-something regarding the Linux kernel's xfrm subsystem represents a critical memory safety flaw rooted in improper handling of compatibility layer data structures during socket buffer operations. The core issue arises within the interaction between xfrm_state_netlink and xfrm_alloc_userspi functions when processing ALLOCSPI requests from 32-bit applications running on a 64-bit kernel, commonly referred to as compat mode. In this scenario, the function dump_one_state is invoked to construct the response for an ALLOCSPI request. This function correctly calls alloc_compat with the appropriate response socket buffer and header, ensuring that the data structure translation from the legacy 32-bit format to the native 64-bit layout occurs accurately within the context of the outgoing message. However, a subsequent call to xfrm_alloc_userspi erroneously invokes alloc_compat again, but this time it passes the original incoming request's socket buffer and its associated header rather than the response buffer.
This redundant translation attempt introduces a severe off-by-four-byte read error due to structural size discrepancies between compatibility and native layouts. Specifically, the compat structure xfrm_userspi_info occupies 228 bytes, whereas its native counterpart requires 232 bytes of memory space. By applying the translator logic to the original request buffer using the larger native layout assumptions, the kernel reads four bytes beyond the declared payload boundary of the user-supplied data. This out-of-bounds read not only exposes sensitive kernel memory contents but also leads to the publication of a translated child object through the frag_list field of the inbound request socket buffer. The frag_list is typically used for scatter-gather I/O operations, and attaching an improperly constructed or partially corrupted object here creates a dangerous state where internal kernel pointers may reference invalid or stale memory regions.
The operational impact escalates significantly due to the asynchronous nature of network packet processing in Linux. A multicast clone of the original request shares the same skb_shared_info structure as the primary request buffer. Consequently, this cloned socket buffer can observe and potentially access the child object that was incorrectly attached via the frag_list during the flawed translation process. When xfrm_user_rcv_msg completes its handling of the initial request, it proceeds to free the associated memory resources. However, because the multicast clone retains a reference or visibility into the shared information structure containing the dangling pointer to the translated child, there exists a race condition where the compat receiver may still be attempting to copy data from this region after the original buffer has been deallocated by the kernel's cleanup routines. This scenario constitutes a classic use-after-free vulnerability, allowing for potential arbitrary code execution or denial of service depending on how an attacker manipulates memory allocation patterns and timing.
From a threat modeling perspective, this flaw aligns with CWE-416 Use After Free, as it involves accessing memory after it has been made available for reuse without proper synchronization or reference counting safeguards. Additionally, the mechanism leverages network packet processing paths which may be accessible to unprivileged users via netlink sockets, potentially mapping to ATT&CK technique T1059 Command and Scripting Interpreter if exploited for lateral movement, though more directly it falls under privilege escalation vectors due to kernel memory corruption. The exploitation requires an attacker to craft specific compat-mode ALLOCSPI requests that trigger the race condition between buffer freeing and concurrent access through multicast clones. This highlights the complexity of maintaining backward compatibility layers in high-performance networking stacks where performance optimizations like shared socket buffers can inadvertently introduce subtle concurrency bugs if not carefully managed.
Mitigation strategies primarily involve applying the upstream kernel patch that removes the redundant conversion call within xfrm_alloc_userspi. By eliminating this second invocation of alloc_compat with the incorrect buffer arguments, the system prevents the erroneous attachment of the translated child to the request's frag_list and stops the out-of-bounds read from occurring in the first place. System administrators should ensure their Linux kernels are updated to versions that include this fix, particularly for systems running mixed 32-bit and 64-bit applications over xfrm interfaces such as IPsec tunnels or virtual private networks. For environments where immediate patching is not feasible, restricting access to netlink sockets used by the xfrm subsystem can reduce the attack surface, although complete isolation of these services from untrusted users is often difficult in multi-tenant cloud infrastructure. Continuous monitoring for anomalous network traffic patterns involving large numbers of ALLOCSPI requests may also aid in detecting attempted exploitation activities before successful memory corruption occurs.