Skip to main content

Linux Kernel CVE-2026-68426

| EUVDEUVD-2026-55612 CRITICAL
2026-08-10 Linux GHSA-g9mw-m3g9-8x3m
Information Disclosure Linux
9.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
9.8 CRITICAL
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.0 HIGH

Triggered by network traffic but only under a narrow crypto-completion race requiring IPsec async offload, so AC:H; impact is primarily kernel crash (A:H) with uncertain, limited C/I.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H
4.0 AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N
SUSE
7.0 HIGH
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Red Hat
7.3 HIGH
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Aug 14, 2026 - 01:53 vuln.today
CVSS changed
Aug 13, 2026 - 23:37 NVD
9.8 (CRITICAL)
Patch available
Aug 10, 2026 - 14:18 EUVD
CVE Published
Aug 10, 2026 - 12:04 cve.org
UNKNOWN (no severity yet)
CVE Published
Aug 10, 2026 - 12:04 cve.org
CRITICAL 9.8

DescriptionCVE.org

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.

AnalysisAI

Use-after-free in the Linux kernel's IPsec transmit path (xfrm) occurs when validate_xmit_xfrm() processes a GSO segment list and async crypto offload steals the final segment via -EINPROGRESS, leaving the list head's ->prev pointing at a segment now owned (and potentially freed) by the crypto engine. validate_xmit_skb_list() then writes through that stale tail pointer, corrupting freed memory; the practical impact is kernel memory corruption and likely crash on systems using IPsec with asynchronous crypto. No public exploit identified at time of analysis, EPSS is low (0.16%), and it is not listed in CISA KEV, so this is a patch-and-move-on issue rather than an active-exploitation emergency.

Technical ContextAI

The bug lives in the kernel networking stack's xfrm (IP transformation / IPsec) egress path. skb_gso_segment() splits a large GSO super-packet into a linked list of segment skbs and, by convention, sets the list head's skb->prev to the last segment - an invariant that validate_xmit_skb_list() depends on to compute its tail (tail = skb->prev). When IPsec is offloaded to an asynchronous crypto engine, a per-segment ->xmit() can return -EINPROGRESS, meaning that segment is unlinked and handed to the crypto hardware/driver. validate_xmit_xfrm() failed to repoint the head's ->prev after removing the last segment, so a subsequent tail->next = skb dereferences memory that may already be freed. This is a classic use-after-free (CWE-416) arising from a broken list invariant, and the CPE data scopes it to cpe:2.3:a:linux:linux, i.e. the mainline kernel. The fix simply repoints skb->prev to the last retained segment before returning.

RemediationAI

Patch available per vendor: upgrade to a fixed stable kernel - 6.18.42 or later in that series, or 7.1.6 / 7.2-rc4 and later - which carry commits bbca7cc3b2b4b10afbfee99b81d9ee78f5423046, 3f4c3919baf0944ad96580467c302bc6c7758b00, or 33e1b0d25ca0d2818c635ff80e6aa0d295e08a98 (https://git.kernel.org/stable/c/33e1b0d25ca0d2818c635ff80e6aa0d295e08a98). Distribution users should apply their vendor's next kernel update rather than back-porting by hand. As an interim compensating control on hosts where you cannot reboot immediately, disabling asynchronous/offloaded IPsec crypto (forcing synchronous software crypto for xfrm) avoids the -EINPROGRESS path that triggers the race, at the cost of reduced IPsec throughput and higher CPU load; alternatively, on systems that do not require IPsec, ensuring xfrm/IPsec is not in use removes exposure entirely. There is no need for network-level blocking since the condition is internal to the egress crypto path.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

CVE-2026-68426 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy