Cloudanix VulnDB

CVE-2026-64132

Critical · 9.8

CVSS

9.8

EPSS

0.5%

Published

Jul 19, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in how Linux handles certain network packets could let remote attackers seize control of the machine or shut it down.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Remote Code Execution
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in ipv6_hop_ioam() where skb_ensure_writable() can trigger pskb_expand_head() reallocation, invalidating the hdr pointer before its opt_len field is passed to ioam6_event().

Why it matters to the business

Remote attackers could achieve arbitrary code execution or cause kernel crashes on any Linux system processing IPv6 traffic containing IOAM options, resulting in full host compromise, data breach, or denial of service; low immediate risk given declining EPSS and absence from KEV.

How an attack unfolds

An attacker sends a crafted IPv6 packet carrying an IOAM hop-by-hop option that reaches ipv6_hop_ioam(); the subsequent skb_ensure_writable() reallocates the data buffer; the stale hdr pointer is then dereferenced inside ioam6_event(), enabling a use-after-free that can be turned into memory corruption.

How to fix it

Apply the upstream fix that refreshes the hdr pointer immediately before the ioam6_event() call; upgrade to a patched Linux kernel once released by your distribution.

How to confirm the fix worked

Inspect the ipv6_hop_ioam() function in the kernel source to confirm the hdr pointer is recalculated after skb_ensure_writable() and before any use of hdr->opt_len.

Typical attack path

  1. Craft and transmit IPv6 packet with IOAM trace option reaching the hop-by-hop handler
  2. Force skb_ensure_writable() to invoke pskb_expand_head() via insufficient headroom or cloning
  3. Trigger use of the now-dangling hdr pointer when ioam6_event() reads hdr->opt_len
  4. Leverage resulting UAF for memory corruption or control-flow hijack

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for oops or panic messages referencing ipv6, ioam6, or skb_expand; correlate with unusual IPv6 traffic containing hop-by-hop options.

What your security team should do

  • Track Linux kernel security advisories for the availability of this fix and schedule rapid deployment
  • Temporarily disable IPv6 IOAM processing if the feature is not required
  • Harden network edge devices to drop unexpected IPv6 hop-by-hop options until patches are applied

The record

In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: refresh hdr pointer before ioam6_event() Reported by Sashiko: In ipv6_hop_ioam(), the hdr pointer is initialized to point into the skb's linear data buffer. Later, the code calls skb_ensure_writable(), which might reallocate the buffer: if (skb_ensure_writable(skb, optoff + 2 + hdr->opt_len)) goto drop; /* Trace pointer may have changed */ trace = (struct ioam6_trace_hdr *)(skb_network_header(skb) + optoff + sizeof(*hdr)); ioam6_fill_trace_data(skb, ns, trace, true); ioam6_event(IOAM6_EVENT_TRACE, dev_net(skb->dev), GFP_ATOMIC, (void *)trace, hdr->opt_len - 2); If the skb is cloned or lacks sufficient linear headroom, skb_ensure_writable() will invoke pskb_expand_head(), which reallocates the skb's data buffer and frees the old one, invalidating pointers to it. While the code recalculates the trace pointer immediately after the call to skb_ensure_writable(), it fails to recalculate the hdr pointer. This patch fixes the above by recalculating the hdr pointer before passing hdr->opt_len to ioam6_event(), so that we avoid any UaF.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities