CVE-2026-53006

What it actually does

This is a Linux kernel IPv6 networking use-after-free condition in the ICMPv6 receive path. The vulnerable code cached pointers to IPv6 source and destination address fields before calling pskb_pull(), a routine that can reallocate or move the packet buffer head. If those cached pointers are later used after the buffer changes, the kernel may reference stale memory. Practical impact is most likely kernel instability or denial of service from specially crafted IPv6/ICMPv6 traffic; depending on kernel build options, memory layout, and reachable code paths, it may also create a limited information disclosure or memory corruption risk. No public exploit maturity is currently reported, EPSS is low at 0.00395, and it is not listed in CISA KEV.

Why it matters to the business

Organizations running vulnerable Linux kernels with IPv6 enabled may be exposed to remotely triggered kernel crashes or network stack instability, which can affect service availability for servers, appliances, containers, virtualization hosts, and network-facing infrastructure. Because this is in the kernel, successful exploitation can disrupt entire systems rather than just one application. Current exploitation likelihood appears low based on the low EPSS score, lack of known exploited status, and no reported public exploit maturity, but kernel networking flaws should still be remediated through normal patch cycles because exposure can be broad and difficult to mitigate at the application layer.

How an attack unfolds

An attacker would target a system that processes IPv6 traffic and send crafted ICMPv6 packets designed to reach the vulnerable icmpv6_rcv() receive path. During packet parsing, the kernel may cache IPv6 header address pointers and then call pskb_pull(), which can alter the socket buffer memory backing those pointers. If the slow-path diagnostic or error-handling logic later dereferences the stale source or destination address pointer, the kernel may access invalid or freed memory. The most realistic outcome is a kernel warning, oops, panic, or networking stack crash resulting in denial of service. Reliable code execution is not indicated by the available information and would likely require additional primitives and favorable kernel conditions.

How to fix it

Apply Linux kernel updates from the relevant distribution, appliance, cloud image, or kernel maintainer that include the upstream fix for the IPv6 icmpv6_rcv() use-after-free issue. No exact fixed package versions were provided in the input, so remediation should be tracked through vendor advisories for each deployed kernel stream. Where immediate patching is not possible, reduce exposure by disabling IPv6 only where operationally safe, restricting unsolicited ICMPv6 from untrusted networks using host or perimeter firewalls, and limiting direct IPv6 reachability to systems that do not require it. Avoid blanket ICMPv6 blocking on production IPv6 networks without testing, because Neighbor Discovery, Path MTU Discovery, Router Advertisements, and other IPv6 functions depend on ICMPv6. Reboot systems after kernel package updates unless using a live-patching mechanism that explicitly covers this fix.

How to confirm the fix worked

Confirm the running kernel version, not only the installed package version, because kernel updates usually require a reboot or successful live patch application. Validate against the appropriate distribution or vendor advisory to ensure the active kernel includes the icmpv6_rcv() fix. Check whether IPv6 is enabled and whether the host accepts ICMPv6 from untrusted networks. Review firewall policy for unnecessary external ICMPv6 exposure while preserving required IPv6 control traffic. In test environments, use kernel debug logs, KASAN-enabled kernels, or packet-fuzzing regression tests to confirm malformed ICMPv6 traffic no longer produces warnings, use-after-free reports, oopses, or panics in icmpv6_rcv(), pskb_pull(), or related IPv6 receive functions.

Typical attack path

1. Identify Linux systems reachable over IPv6, especially internet-facing or adjacent-network hosts that accept ICMPv6 traffic.
2. Send crafted ICMPv6 packets intended to exercise the vulnerable icmpv6_rcv() parsing and slow-path handling logic.
3. Trigger packet-buffer manipulation through pskb_pull(), causing previously cached IPv6 header address pointers to become stale.
4. Cause the kernel to dereference stale memory in the ICMPv6 receive path.
5. Observe system instability, kernel oops/panic, dropped networking, or service outage as the primary exploitation result.

How to detect it

Retrospective exploitation detection is difficult because this vulnerability may leave few application-level traces and exploitation would primarily appear as malformed IPv6/ICMPv6 traffic followed by kernel instability. Review kernel logs, system journals, crash dumps, hypervisor reset events, and availability monitoring for crashes or oopses around the time of inbound ICMPv6 traffic. Useful log sources include journald, dmesg, /var/log/kern.log, /var/log/messages, netconsole output, kdump/vmcore artifacts, host firewall logs, perimeter firewall logs, IDS/IPS telemetry, Zeek/Suricata records, and packet captures. Look for kernel warnings or KASAN reports referencing icmpv6_rcv(), pskb_pull(), skb head changes, use-after-free, general protection faults, page faults, or kernel panics in IPv6 receive handling. Correlate those events with spikes in ICMPv6 traffic, malformed IPv6 packets, unusual ICMPv6 types/codes, fragmented IPv6 traffic, or repeated probes from the same source addresses. There are no known threat actors, ransomware campaigns, or public exploit indicators provided for this CVE, so detection should focus on behavioral evidence rather than fixed attacker infrastructure.

• icmpv6_rcv
• pskb_pull
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• kernel BUG
• kernel panic
• general protection fault
• Oops:
• IPv6:
• ICMPv6
• skb->head
• /var/log/kern.log
• /var/log/messages
• /var/crash
• vmcore
• kdump

What your security team should do

• Inventory Linux systems with IPv6 enabled, prioritizing internet-facing servers, network appliances, Kubernetes/container hosts, virtualization hosts, and high-availability infrastructure.
• Track vendor advisories and upgrade to kernel packages that include the upstream fix; ensure systems are rebooted into the fixed kernel or covered by a verified live patch.
• Prioritize remediation according to exposure: externally reachable IPv6 systems first, then internal high-value or high-availability systems, then remaining fleet.
• Review host and perimeter firewall rules to reduce unnecessary ICMPv6 exposure from untrusted networks while preserving required IPv6 functionality.
• Add monitoring for kernel oops, panic, KASAN, or use-after-free messages referencing icmpv6_rcv(), pskb_pull(), ICMPv6, or IPv6 packet receive paths.
• If unexplained crashes occurred on IPv6-enabled systems, preserve kernel logs, crash dumps, packet captures, and netfilter/firewall logs for investigation.
• Because EPSS is low, there is no KEV listing, and no exploit maturity is reported, handle this as a normal-to-elevated kernel patching priority rather than an emergency mass-disconnect event unless local exposure is high.