Skip to main content
VulnerabilityPublished Updated

CVE-2026-68426: Linux kernel · Use After Free

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 9.8 Critical · fixed in bbca7cc3b2b4b10afbfee99b81d9ee78f5423046 : patch Linux kernel as a priority.

Data as of 26 Oct 2026, 17:30 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.3% chance of exploitation in 30 days – higher than 31% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers can reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in bbca7cc3b2b4b10afbfee99b81d9ee78f5423046, b58731e0570bfd3989999fc2baf9ee4fecd5bec6, 4927ab8a8acc8db4fad33e803d1d35e0b16cef83 +2
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 10 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ f53c723902d1ac5f0b0a11d7c9dcbff748dde74e, < bbca7cc3b2b4b10afbfee99b81d9ee78f5423046
Fixed in
  • bbca7cc3b2b4b10afbfee99b81d9ee78f5423046
LinuxLinuxAffected
  • ≥ f53c723902d1ac5f0b0a11d7c9dcbff748dde74e, < b58731e0570bfd3989999fc2baf9ee4fecd5bec6
Fixed in
  • b58731e0570bfd3989999fc2baf9ee4fecd5bec6
LinuxLinuxAffected
  • ≥ f53c723902d1ac5f0b0a11d7c9dcbff748dde74e, < 4927ab8a8acc8db4fad33e803d1d35e0b16cef83
Fixed in
  • 4927ab8a8acc8db4fad33e803d1d35e0b16cef83
LinuxLinuxAffected
  • ≥ f53c723902d1ac5f0b0a11d7c9dcbff748dde74e, < 33e1b0d25ca0d2818c635ff80e6aa0d295e08a98
Fixed in
  • 33e1b0d25ca0d2818c635ff80e6aa0d295e08a98
LinuxLinuxAffected
  • ≥ f53c723902d1ac5f0b0a11d7c9dcbff748dde74e, < 3f4c3919baf0944ad96580467c302bc6c7758b00
Fixed in
  • 3f4c3919baf0944ad96580467c302bc6c7758b00
LinuxLinuxAffected
  • =4.16
Fixed in–

Description

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.

References

Community reviews

Loading reviews…