CVE-2026-92489 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
xfrm: Fix skb double-free in xfrm_dev_direct_output()
A return value other than 1 from local_out() means that the skb has been consumed or its ownership was transferred. xfrm_dev_direct_output() nevertheless frees the skb on this path, causing a double-free when netfilter drops the packet and invalidating any other owner.
Return the local_out() result directly, matching the ownership handling in xfrm_output_resume().
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel networking subsystem contains a critical memory management flaw within the IPsec implementation, specifically affecting the function xfrm_dev_direct_output. This vulnerability arises from an incorrect assumption regarding packet buffer ownership and lifecycle management during network transmission operations. The core issue lies in how the code handles the return value of the local_out() function call, which is responsible for processing packets through the networking stack before they are transmitted or dropped by netfilter rules.
In normal operation, when a kernel component calls local_out(), it expects to receive specific feedback about what happened to the socket buffer containing the packet data. A return value indicating success typically implies that the caller retains ownership of the buffer and is responsible for its eventual release if necessary. However, any other return value signifies that the skb has been consumed by downstream processing or that ownership was transferred elsewhere in the stack. The vulnerability occurs because xfrm_dev_direct_output() fails to check this return code properly before proceeding to free the socket buffer unconditionally.
This logic error leads directly to a double-free condition when netfilter decides to drop the packet during its inspection phase. When netfilter drops the packet, it consumes or frees the skb as part of its standard cleanup procedure. Because xfrm_dev_direct_output() subsequently attempts to free the same memory block again without verifying that ownership was already transferred, it triggers a use-after-free scenario. This type of error corrupts kernel heap metadata and can lead to system instability, crashes, or potentially allow an attacker with local access to execute arbitrary code by manipulating allocation patterns in the kernel space.
The operational impact of this vulnerability is significant for systems relying on IPsec tunneling or transport mode configurations where direct output paths are utilized. An attacker who can trigger network traffic that matches specific netfilter drop rules could exploit this race condition to destabilize the host system. In severe cases, careful exploitation might allow privilege escalation from a standard user account to root level by overwriting critical kernel structures through heap corruption techniques associated with double-free vulnerabilities.
To mitigate this risk, developers must ensure that socket buffer ownership semantics are strictly adhered to throughout the networking stack. The fix involves modifying xfrm_dev_direct_output() to return the result of local_out() directly rather than attempting manual cleanup on paths where ownership has been transferred. This aligns the behavior with other similar functions like xfrm_output_resume(), which correctly handle variable outcomes from lower-level network processing calls. System administrators should apply kernel updates that include this patch immediately, particularly for environments running active IPsec connections subject to complex firewall rulesets.
From a classification perspective, this vulnerability maps closely to CWE-415 Double Free, as the root cause is the attempt to deallocate memory twice in quick succession without proper state tracking. It also relates to CWE-20 Improper Input Validation since the code fails to validate the return status of a critical function call before proceeding with resource release operations. In terms of attack vectors and techniques, this flaw could be leveraged within ATT&CK framework contexts involving exploitation for privilege escalation or defense evasion through system crash induction, although it primarily serves as an initial vector for further kernel-level attacks rather than standalone remote code execution without additional conditions.
Long-term prevention requires rigorous static analysis tools to detect mismatched ownership transfers in network driver and protocol stack implementations. Developers should adopt defensive programming practices that explicitly check return codes from functions known to potentially transfer resource ownership. Regular auditing of socket buffer handling paths across the kernel tree helps identify similar patterns before they reach production environments. Maintaining clear documentation about which components own specific resources at each stage of packet processing reduces ambiguity and prevents such logical errors in future code revisions.