CVE-2026-64423

What it actually does

This is a Linux kernel IPv4 IGMP use-after-free flaw in multicast group handling during network device destruction. When a network device is torn down, multicast membership objects can be scheduled for RCU reclamation without first being removed from the device multicast hash table. Concurrent RCU readers can still find the stale multicast group entry and access freed memory in paths such as ip_check_mc_rcu(), potentially causing kernel memory corruption. With local access, an attacker who can manipulate multicast socket membership and trigger network device teardown may be able to crash the kernel or, with a reliable exploit, escalate privileges to kernel/root level.

Why it matters to the business

Successful exploitation could allow a local user or compromised low-privilege process to disrupt Linux systems or gain full control of the host. The main operational risk is denial of service through kernel panic or instability, with higher-impact risk of privilege escalation where exploit reliability is achieved. This is especially relevant for systems that allow untrusted local workloads, containers, network namespaces, virtual networking, CI runners, shared development hosts, or multi-tenant Linux environments. The issue is not currently listed in CISA KEV, has low EPSS, and has no reported exploit maturity in the provided data, but kernel local privilege-escalation issues should still be prioritized on exposed multi-user or container-dense systems.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged or low-privileged user. They create or use sockets to join IPv4 multicast groups, causing multicast membership structures to be allocated in the kernel. The attacker then triggers destruction of the associated network device or virtual interface while concurrent packet-processing or multicast lookup paths can still traverse the device multicast hash table. Because the vulnerable kernel leaves freed multicast group objects discoverable through the hash table until after RCU reclamation, a race can result in ip_check_mc_rcu() or related receive-path code reading memory that has already been freed. In the simplest case this produces a kernel crash. A more advanced attacker may attempt heap grooming and race timing to convert the use-after-free into controlled memory corruption and privilege escalation.

How to fix it

Upgrade the Linux kernel to a version that includes the fix for the IPv4 IGMP multicast group cleanup logic, specifically the change that removes multicast groups from mc_hash with ip_mc_hash_remove() before scheduling them for RCU reclamation during device destruction. Because no product-specific fixed versions were provided, use the fixed kernel packages supplied by the operating system or appliance vendor for CVE-2026-64423. After updating, reboot into the patched kernel and remove or decommission old vulnerable kernels where practical. As interim risk reduction, restrict local shell access, limit untrusted workloads, reduce access to network namespace or virtual interface creation, constrain container capabilities such as CAP_NET_ADMIN where not required, and use kernel lockdown, LSM policy, seccomp, and container isolation controls to reduce exploitability. These mitigations do not replace patching.

How to confirm the fix worked

Confirm that systems are booted into a vendor kernel build that includes the CVE-2026-64423 fix, not merely that the package is installed. Validate with uname -a, package-manager kernel version checks, and vendor advisories or changelogs referencing the IPv4 IGMP mc_hash cleanup fix. Where source validation is possible, verify that ip_mc_destroy_dev() removes multicast group entries from the multicast hash table before calling ip_ma_put() or otherwise scheduling RCU reclamation. Review running systems for old kernels still present after package updates and ensure reboots have completed. For exposure assessment, prioritize Linux systems that permit local untrusted users, containers, network namespaces, virtual networking, or CAP_NET_ADMIN-like capabilities.

Typical attack path

1. Gain local execution on a vulnerable Linux host as a low-privileged user or process.
2. Create IPv4 sockets and join multicast groups to allocate IGMP multicast membership objects.
3. Create, use, or influence destruction of a network device, virtual interface, or network namespace associated with those memberships.
4. Generate concurrent IPv4/UDP or multicast-related traffic to exercise receive-side multicast lookup paths.
5. Race device destruction against RCU readers traversing the multicast hash table.
6. Trigger use-after-free in kernel networking code, causing a crash or attempting memory corruption for privilege escalation.

How to detect it

Look for evidence of attempted or successful exploitation in kernel logs, crash dumps, audit logs, and workload activity around network namespace or interface teardown. Relevant sources include dmesg, journald, /var/log/kern.log, /var/log/messages, kernel crash dumps/vmcores, KASAN reports, container runtime logs, orchestration audit logs, and Linux auditd records for namespace or network administration activity. Suspicious patterns include repeated creation and deletion of network namespaces or virtual interfaces, joins to IPv4 multicast groups followed by interface teardown, unexplained kernel oops or panics in IGMP/multicast receive paths, and crashes involving ip_check_mc_rcu(), udp_v4_early_demux(), ip_rcv_finish_core(), process_backlog(), or rcu_core(). Because this is a memory-corruption race in kernel code, successful exploitation may leave no clean application-layer IOC; absence of logs does not prove absence of exploitation. On systems with KASAN or debug kernels, search for slab-use-after-free reports referencing ip_check_mc_rcu. On production systems, correlate kernel crashes with local user activity, container lifecycle events, privileged container launches, CAP_NET_ADMIN usage, and network device deletion events.

• BUG: KASAN: slab-use-after-free in ip_check_mc_rcu
• slab-use-after-free in ip_check_mc_rcu
• ip_check_mc_rcu+
• udp_v4_early_demux+
• ip_rcv_finish_core+
• ____ip_mc_inc_group+
• __ip_mc_join_group+
• do_ip_setsockopt+
• ip_setsockopt+
• ip_mc_destroy_dev
• ip_ma_put
• ip_mc_hash_remove
• rcu_core+
• process_backlog+
• net_rx_action+
• KASAN: slab-use-after-free
• kernel BUG at
• Oops:
• Kernel panic - not syncing

What your security team should do

• Inventory Linux kernels across servers, endpoints, appliances, containers hosts, and virtualization platforms; identify builds lacking the IPv4 IGMP multicast cleanup fix.
• Prioritize patching and rebooting multi-user systems, container hosts, Kubernetes nodes, CI/CD runners, developer workstations, and systems where untrusted code can run locally.
• Restrict CAP_NET_ADMIN, network namespace creation, virtual interface management, and privileged container execution for untrusted workloads until patched.
• Monitor kernel logs for KASAN, slab-use-after-free, kernel oops, panic, or crashes involving ip_check_mc_rcu, udp_v4_early_demux, IGMP, multicast, or device teardown paths.
• Treat unexplained kernel crashes on vulnerable systems as potentially security-relevant and preserve logs, vmcore dumps, and workload context for forensic review.
• Track vendor advisories for exact fixed kernel package versions and ensure systems are rebooted into the patched kernel after installation.