CVE-2026-68426

Critical · 9.8

CVSS

9.8

EPSS

0.4%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A flaw in the Linux kernel's network security processing can let attackers crash systems or potentially take them over by sending specially crafted network traffic.

Exploitation: Remote Unauthenticated
Attacker needs: None
Complexity: Low
Impact: Full Compromise
Component: OS kernel
Class: Use After Free
Remediation: Patch
Effort: Medium
Patch risk: Low

What it actually does

Use-after-free in Linux kernel xfrm: validate_xmit_skb_list writes through a stale skb->prev pointer when async crypto (-EINPROGRESS) steals the final GSO segment, leaving the list head pointing at a freed skb.

Why it matters to the business

Linux-based network appliances, servers, or routers handling IPsec or other xfrm-accelerated traffic can experience kernel crashes or potential remote code execution, leading to denial of service or full host compromise.

How an attack unfolds

An attacker sends specially crafted network packets that trigger GSO segmentation under xfrm with async crypto enabled; when the final segment is stolen, the subsequent list-walking code dereferences a dangling prev pointer, resulting in a use-after-free that can be leveraged for memory corruption.

How to fix it

Apply the upstream fix that updates skb->prev to the last retained segment before returning from validate_xmit_xfrm; rebuild and deploy a patched kernel; disable async crypto offload or GSO on xfrm interfaces as a temporary mitigation if patching is delayed.

How to confirm the fix worked

Confirm the kernel source contains the repoint of skb->prev to the last retained segment; run regression tests exercising xfrm + GSO + async crypto paths; monitor for crashes in validate_xmit_skb_list after upgrade.

Typical attack path

Send GSO-eligible packets to a system using xfrm with async crypto offload
Force the crypto engine to return -EINPROGRESS on the last segment, unlinking it without updating head->prev
Trigger validate_xmit_skb_list to follow the stale prev pointer and perform an arbitrary write
Exploit the resulting use-after-free for kernel memory corruption or code execution

How to detect it

Review kernel crash dumps and logs for oops/panics referencing validate_xmit_skb_list or xfrm GSO handling; correlate with network flows that trigger async crypto paths; inspect system call traces involving sendmsg on xfrm-protected sockets.

What your security team should do

Prioritize patching all Linux kernels that use xfrm with async crypto and GSO within the next maintenance window
Add kernel version checks to asset inventory for affected xfrm-enabled systems
Temporarily disable async crypto offload on xfrm devices if immediate patching is not feasible
Update kernel build pipelines to include the corrected xfrm code path

The record

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.

Affected packages

Ecosystem	Package	Introduced	Fixed