CVE-2026-68426 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
xfrm: fix stale skb->prev after async crypto steals a GSO segment
skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev).
When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free.
Repoint skb->prev at the last retained segment before returning.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
This vulnerability exists within the linux kernel's ipsec xfrm subsystem where a use-after-free condition can occur during asynchronous cryptographic operations on generic segmentation offload gso segments. The flaw stems from improper management of linked list pointers when segments are stolen by async crypto operations, creating a dangerous stale reference that leads to memory corruption.
The technical root cause involves the skb_gso_segment() function which establishes an invariant where the segment list head maintains its ->prev pointer pointing to the last segment in the list. This invariant is crucial for validate_xmit_skb_list() which uses this relationship to properly set its tail pointer during packet transmission validation. When validate_xmit_xfrm() processes a GSO list and encounters segments that are asynchronously stolen by crypto operations returning -einprogress, these segments are unlinked from the list but the head's ->prev pointer remains unchanged, creating a dangling reference.
The operational impact of this vulnerability manifests as a use-after-free condition when the validation routine later executes tail->next = skb, attempting to write through a stale pointer that may have been freed by the crypto engine. This memory corruption scenario can potentially lead to privilege escalation or system instability depending on exploitation circumstances. The vulnerability specifically occurs when the last segment in the list is stolen by async crypto operations, leaving the head pointer pointing to freed memory.
This issue maps to CWE-416 Use After Free and aligns with ATT&CK technique T1068 Exploitation for Privilege Escalation through kernel memory corruption vulnerabilities. The fix implements a targeted correction where skb->prev is repointed at the last retained segment before function return, ensuring the invariant remains valid throughout the async crypto operation lifecycle. This remediation maintains the integrity of the linked list structure while preserving proper pointer semantics during asynchronous cryptographic processing.
The vulnerability demonstrates a classic race condition in kernel memory management where asynchronous operations fail to properly update data structures that other kernel components depend upon for correctness. The fix addresses the specific inconsistency between the expected behavior of GSO segment handling and the actual implementation when async crypto steals segments from the processing list, ensuring proper pointer maintenance throughout the entire packet transmission pipeline.
This represents a critical kernel vulnerability affecting systems utilizing ipsec xfrm with generic segmentation offload capabilities where asynchronous cryptographic operations are employed. The fix ensures that all kernel components maintaining references to packet lists maintain consistent state information even when asynchronous operations modify the underlying data structures, preventing the cascading memory corruption that could otherwise occur during transmission validation phases.