CVE-2026-53275

What it actually does

This is a Linux kernel IPv6 multicast handling use-after-free in Multicast Listener Discovery (MLD) query processing. While parsing an incoming MLD query, the kernel stores a pointer into packet buffer memory for the multicast group address. Later, packet-buffer expansion or header reallocation through pskb_may_pull()/__pskb_pull_tail() can free or move that memory, but the MLD workqueue code still dereferences the stale pointer. The practical result is kernel memory corruption and likely kernel crash/panic when a crafted IPv6 MLD query is processed. In theory, use-after-free flaws can sometimes be developed into privilege escalation or code execution, but the available information does not indicate a public exploit or demonstrated code execution path for this issue.

Why it matters to the business

Affected Linux systems with IPv6 multicast processing exposed to untrusted local network traffic may be susceptible to remotely triggered instability or denial of service. Because MLD is link-local IPv6 traffic, exploitation is most relevant from the same Layer 2 network segment, compromised internal hosts, malicious Wi-Fi clients, hostile guests, or adjacent cloud/container networks where such traffic is permitted. The CVE is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no known exploit maturity, so broad internet-scale exploitation is unlikely; however, kernel crashes on servers, appliances, hypervisors, network nodes, or embedded Linux devices can still cause operational outages.

How an attack unfolds

An attacker first obtains the ability to send IPv6 packets on the same local network segment as a vulnerable Linux host. They then craft MLD query traffic that causes the Linux IPv6 multicast parser to take a pointer to the multicast group address from the packet buffer and later force packet-buffer header movement or reallocation during processing. When the deferred MLD workqueue continues handling the query, it dereferences the stale pointer, triggering a slab use-after-free condition in the kernel. On hardened or instrumented kernels this may produce KASAN reports; on production kernels it may manifest as a kernel oops, panic, network stack failure, or system reboot. There is no public evidence in the provided data of active exploitation, named threat actors, ransomware use, or a weaponized exploit.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the IPv6 MLD use-after-free, where the multicast group address is copied during initial parsing instead of retaining a pointer into mutable skb memory. Use vendor-supported kernel packages from the relevant Linux distribution, appliance vendor, cloud image provider, or embedded device supplier. No exact fixed package versions were provided, so track distribution advisories for this CVE and update to the first patched kernel or later. If immediate patching is not possible, reduce exposure by blocking untrusted IPv6 MLD/ICMPv6 type 130 traffic at network boundaries where safe, segmenting untrusted clients, disabling IPv6 only where operationally acceptable, and preventing guest or untrusted workloads from injecting link-local IPv6 multicast traffic onto sensitive host networks. Avoid blanket ICMPv6 blocking without testing, because some ICMPv6 traffic is required for correct IPv6 operation.

How to confirm the fix worked

Confirm the running kernel version is from a vendor release that includes the fix for this CVE, not merely that an updated package is installed but not booted. Validate with package manager advisory tooling, kernel changelogs, or vendor CVE trackers, and verify the active kernel after reboot using standard system inventory commands. Where source-based validation is possible, confirm the IPv6 MLD query parsing logic copies the multicast group address rather than preserving a pointer into the skb header across pskb_may_pull() operations. For exposure validation, determine whether IPv6 is enabled and whether untrusted adjacent systems can send ICMPv6 MLD Listener Query packets to the host. For mitigation validation, confirm network controls drop or restrict ICMPv6 type 130 MLD queries from untrusted segments while preserving required IPv6 functionality.

Typical attack path

1. Gain adjacency to the target network segment where IPv6 link-local multicast traffic can reach the vulnerable Linux system.
2. Identify hosts that process IPv6 MLD traffic, such as Linux servers, appliances, routers, containers, or virtualization hosts with IPv6 enabled.
3. Send crafted ICMPv6 MLD Listener Query packets designed to exercise the vulnerable parsing path and trigger packet-buffer reallocation.
4. Cause the MLD workqueue to dereference a stale multicast group address pointer after the underlying skb memory has been freed or moved.
5. Trigger kernel memory corruption, typically resulting in a crash, oops, panic, or denial of service.

How to detect it

Look for evidence of kernel crashes or memory-corruption reports associated with IPv6 MLD processing. Primary log sources include kernel ring buffer output, syslog, journald, crash dump infrastructure, hypervisor console logs, appliance system logs, and EDR telemetry that captures kernel oops or panic messages. Search for call traces containing __mld_query_work, mld_query_work, net/ipv6/mcast.c, pskb_expand_head, __pskb_pull_tail, or KASAN slab-use-after-free messages. Network telemetry can help correlate suspected exploitation: inspect packet captures, NDR, Zeek, Suricata, firewall, switch, or router logs for unusual bursts of ICMPv6 MLD Listener Query traffic, especially ICMPv6 type 130, from non-router endpoints or untrusted segments shortly before crashes or reboots. Because successful exploitation may only leave a crash and not a durable on-disk artifact, correlation between abnormal MLD traffic and kernel failure timing is important. Also review reboot histories, kernel panic dumps, kdump/vmcore files, and availability-monitoring events for unexplained restarts of IPv6-enabled Linux hosts.

• BUG: KASAN: slab-use-after-free in __mld_query_work
• __mld_query_work
• mld_query_work
• net/ipv6/mcast.c:1512
• net/ipv6/mcast.c:1495
• pskb_expand_head
• __pskb_pull_tail
• Workqueue: mld mld_query_work
• ICMPv6 type 130
• MLD Listener Query
• Multicast Listener Query
• Next Header: ICMPv6
• slab-use-after-free
• kworker/
• kernel panic
• kernel oops

What your security team should do

• Prioritize patching internet-facing, network-facing, virtualization, container-host, appliance, and multi-tenant Linux systems where adjacent attackers may be able to send IPv6 multicast traffic.
• Inventory Linux kernels across servers, appliances, network devices, embedded systems, and cloud images; map them to vendor advisories for this CVE and schedule reboot into patched kernels.
• Review local network segmentation to ensure guest, Wi-Fi, lab, container, and untrusted workload networks cannot inject MLD traffic toward critical infrastructure.
• Monitor kernel logs for MLD-related crashes, use-after-free reports, kernel oops messages, unexpected reboots, or repeated ICMPv6 MLD query bursts.
• If patching is delayed, apply narrowly scoped filtering for untrusted ICMPv6 MLD Listener Query traffic and document any IPv6 operational impact.
• Treat suspicious crashes preceded by unusual IPv6 multicast or ICMPv6 type 130 activity as potential exploitation attempts, even though public exploit maturity is currently listed as none.