CVE-2026-63924

What it actually does

This is a Linux kernel IPv6 memory-safety flaw in Hop-by-Hop extension header handling for IPv6 jumbograms. The vulnerable path calls ipv6_hop_jumbo(), which can invoke pskb_trim_rcsum() and alter socket buffer pointers, but subsequent code may continue using a stale network-header pointer. In the worst case, a remotely supplied IPv6 packet can trigger memory corruption in kernel context, potentially causing kernel crashes, denial of service, or, depending on allocator state and mitigations, possible privilege-impacting code execution. The CVSS vector indicates unauthenticated network reachability with no user interaction and high confidentiality, integrity, and availability impact, although EPSS is currently low and no public exploit maturity is reported.

Why it matters to the business

Systems that process IPv6 traffic may be exposed to remote kernel-level compromise or service disruption from specially crafted IPv6 packets. Operational impact can include unexpected host crashes, degraded availability of Linux servers, network appliances, containers relying on the host kernel, and infrastructure services. Because this is in the kernel networking stack, successful exploitation could affect many workloads on the same host. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low observed exploitation probability, but the technical severity warrants timely patching for internet-facing or IPv6-enabled systems.

How an attack unfolds

An attacker targets a Linux system that accepts IPv6 traffic and sends crafted IPv6 packets containing Hop-by-Hop extension header data involving the Jumbo Payload option. During packet processing, the kernel enters the IPv6 extension-header parsing path and calls ipv6_hop_jumbo(). That function may trim or adjust the socket buffer through pskb_trim_rcsum(), which can invalidate previously derived packet header pointers. Vulnerable kernel code then continues processing with an outdated pointer, creating a memory-corruption condition in kernel space. Depending on kernel version, configuration, memory layout, and hardening features, the immediate result may be a kernel warning, crash, or panic; in a more advanced exploitation scenario, memory corruption could be shaped toward broader compromise.

How to fix it

Upgrade affected Linux kernels to vendor-supported fixed builds that include the ipv6/exthdrs fix to refresh the network-header pointer after ipv6_hop_jumbo(). Because no exact fixed versions were provided, use distribution advisories from the relevant Linux vendor or appliance supplier and confirm the patch is included in the running kernel package. Prioritize internet-facing, IPv6-enabled, multi-tenant, high-availability, and security-sensitive systems. If immediate patching is not possible, reduce exposure by disabling IPv6 where it is not required, filtering IPv6 Hop-by-Hop extension headers at network boundaries where operationally safe, and restricting untrusted IPv6 traffic to affected hosts. Validate that mitigations do not break legitimate IPv6 services before broad deployment.

How to confirm the fix worked

Confirm the running kernel version has the vendor fix for the IPv6 extension-header jumbogram handling issue, not merely that an updated package is installed. Reboot systems when required so the fixed kernel is active. Check package manager history, kernel changelogs, vendor advisories, and live kernel version output such as uname -a. Validate network exposure by confirming whether IPv6 is enabled and whether inbound IPv6 Hop-by-Hop extension headers can reach the host. Where feasible, use controlled packet-filter testing to verify that boundary controls drop unwanted IPv6 Hop-by-Hop traffic. Review kernel logs after patching or mitigation for absence of recurring IPv6 extension-header related crashes, warnings, or panics.

Typical attack path

1. Identify Linux hosts, appliances, or services reachable over IPv6.
2. Confirm that IPv6 traffic, especially packets with extension headers, is accepted by the target path.
3. Send specially crafted IPv6 packets using Hop-by-Hop extension headers and a Jumbo Payload option to exercise the vulnerable parsing path.
4. Trigger stale pointer use after socket buffer adjustment inside the kernel networking stack.
5. Cause kernel instability, crash, or potentially gain further control depending on exploit reliability and target hardening.
6. Use resulting disruption or compromise to impact hosted services or pivot from the affected system if code execution is achieved.

How to detect it

To assess possible prior exploitation, review kernel logs, system journals, crash dumps, and network telemetry for evidence of malformed IPv6 Hop-by-Hop or jumbogram packets followed by kernel warnings, oopses, panics, reboots, or service outages. Relevant log sources include journald, /var/log/kern.log, /var/log/messages, dmesg output, kdump/vmcore artifacts, EDR kernel crash telemetry, firewall logs, IDS/IPS alerts, packet captures, and NetFlow/IPFIX records that preserve IPv6 extension-header metadata. Look for suspicious inbound IPv6 traffic where the IPv6 Next Header is Hop-by-Hop Options, Payload Length is zero, and the Jumbo Payload option is present, especially if followed closely by kernel instability. Also search for crash traces referencing IPv6 extension-header parsing, ipv6_hop_jumbo(), pskb_trim_rcsum(), skb pointer handling, KASAN reports, general protection faults, NULL pointer dereferences, use-after-free reports, or slab corruption. Absence of logs does not prove absence of exploitation, because malformed packet attempts may not be logged unless packet capture, firewall logging, IDS, or kernel crash collection was enabled.

• ipv6_hop_jumbo
• pskb_trim_rcsum
• KASAN: use-after-free
• KASAN: slab-out-of-bounds
• general protection fault
• kernel BUG at net/ipv6/exthdrs.c
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic - not syncing
• IPv6 Hop-by-Hop Options
• Jumbo Payload
• IPv6 Next Header: Hop-by-Hop Options
• ip6[6] == 0
• ip6[4:2] == 0
• IPv6 option type 0xc2
• net/ipv6/exthdrs.c

What your security team should do

• Inventory Linux systems and appliances with IPv6 enabled, prioritizing externally reachable assets.
• Apply vendor kernel updates containing the IPv6 Hop-by-Hop jumbogram pointer refresh fix and reboot into the fixed kernel.
• If patching is delayed, filter or rate-limit untrusted IPv6 Hop-by-Hop extension headers at firewalls, routers, load balancers, or host firewalls where feasible.
• Disable IPv6 on systems where it is not required and where disabling it is operationally safe.
• Increase monitoring for kernel crashes, panics, KASAN reports, and malformed IPv6 extension-header traffic.
• Review perimeter and host telemetry for unusual volumes of IPv6 packets with Hop-by-Hop headers or Jumbo Payload options.
• Track vendor advisories because exact affected and fixed kernel versions vary by distribution and backport policy.
• Treat exploitation probability as currently low due to low EPSS and no known KEV listing, but remediate based on high technical severity and remote unauthenticated reachability.