CVE-2026-64423 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
ipv4: igmp: remove multicast group from hash table on device destruction
When a device is destroyed under RTNL, ip_mc_destroy_dev() iterates through the multicast list and calls ip_ma_put() on each membership, scheduling them for RCU reclamation. However, they are not unlinked from the device's multicast hash table (mc_hash).
Since the device remains published in dev->ip_ptr until after ip_mc_destroy_dev() completes, concurrent RCU readers traversing mc_hash can still locate and access the multicast group after its refcount is decremented. If the RCU callback runs and frees the group while a reader is accessing it, a use-after-free occurs.
Fix this by unlinking the multicast group from mc_hash using ip_mc_hash_remove() before scheduling it for reclamation.
BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x149/0x3f0 Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276
Call Trace: <IRQ> dump_stack_lvl+0x67/0x90 print_report+0x175/0x7c0 kasan_report+0x147/0x180 ip_check_mc_rcu+0x149/0x3f0 udp_v4_early_demux+0x36d/0x12d0 ip_rcv_finish_core+0xb8b/0x1390 ip_rcv_finish+0x54/0x120 NF_HOOK+0x213/0x2b0 __netif_receive_skb+0x126/0x340 process_backlog+0x4f2/0xf00 __napi_poll+0x92/0x2c0 net_rx_action+0x583/0xc60 handle_softirqs+0x236/0x7f0 do_softirq+0x57/0x80 </IRQ>
Allocated by task 2239: kasan_save_track+0x3e/0x80 __kasan_kmalloc+0x72/0x90 ____ip_mc_inc_group+0x31a/0xa40 __ip_mc_join_group+0x334/0x3f0 do_ip_setsockopt+0x16fa/0x2010 ip_setsockopt+0x3f/0x90 do_sock_setsockopt+0x1ad/0x300
Freed by task 0: kasan_save_track+0x3e/0x80 kasan_save_free_info+0x40/0x50 __kasan_slab_free+0x3a/0x60 __rcu_free_sheaf_prepare+0xd4/0x220 rcu_free_sheaf+0x36/0x190 rcu_core+0x8d9/0x12f0 handle_softirqs+0x236/0x7f0
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/25/2026
This vulnerability represents a use-after-free condition in the Linux kernel's multicast networking implementation that arises during device destruction operations. The issue occurs specifically within the ipv4 internet group management protocol (igmp) subsystem where multicast groups are not properly removed from the device's multicast hash table before being scheduled for reclamation. The flaw exists in the ip_mc_destroy_dev() function which processes multicast memberships by calling ip_ma_put() on each entry, but fails to unlink these entries from the mc_hash table that serves as the central registry for multicast group information.
The technical root cause stems from a race condition between concurrent RCU (Read-Copy-Update) readers and the reclamation process. When a network device is destroyed under the RTNL (Routing Netlink) lock, the device's multicast hash table continues to contain references to multicast groups even after their reference counts have been decremented. Since the device structure remains accessible through dev->ip_ptr until after ip_mc_destroy_dev() completes, any RCU reader traversing mc_hash can still locate and access these multicast group entries. If an RCU callback executes and frees a multicast group while another thread is still accessing it, the system experiences a use-after-free condition that can lead to memory corruption and potential privilege escalation.
The vulnerability manifests through kernel address sanitizer (KASAN) detection showing a slab-use-after-free error in the ip_check_mc_rcu function where a 4-byte read occurs at address ffff888009bf1408. The call trace demonstrates how the issue originates from multicast group creation through __ip_mc_join_group and ultimately leads to a crash when RCU readers attempt to access freed memory. The allocation history shows that the multicast group was created by task 2239 during ip_mc_join_group operations, while the freeing occurs in task 0 as part of the RCU callback mechanism.
This vulnerability aligns with CWE-415: Double Free and CWE-416: Use After Free categories from the Common Weakness Enumeration catalog, representing a classic memory safety issue where objects are accessed after being freed. The ATT&CK framework categorizes this under T1068: Exploitation for Privilege Escalation as it represents an opportunity for local privilege escalation through kernel memory corruption. The flaw specifically impacts the Network Service and Defense Evasion tactics by compromising system stability and potentially enabling unauthorized access to kernel memory regions.
The fix implements proper synchronization by calling ip_mc_hash_remove() before scheduling multicast groups for RCU reclamation, ensuring that entries are removed from the hash table before any potential freeing operations occur. This approach follows established kernel patterns for safe removal of data structures from concurrent-access data structures and prevents the race condition between readers and writers that leads to the use-after-free scenario. The solution maintains the integrity of the multicast hash table while preserving all other functionality of the multicast subsystem.
The operational impact of this vulnerability extends beyond simple system crashes as it represents a potential security risk in environments where local users or malicious actors could exploit the memory corruption to gain elevated privileges or cause denial-of-service conditions. Systems running kernel versions containing this vulnerability require immediate patching to prevent exploitation, particularly in server environments where network device destruction operations are common during network configuration changes or hardware hot-plugging scenarios. The vulnerability demonstrates the critical importance of proper synchronization in kernel-level data structure management and highlights the need for careful consideration of RCU usage patterns in concurrent systems.
Security practitioners should monitor for this vulnerability through standard patch management processes and consider implementing additional network monitoring to detect unusual device destruction patterns that might indicate exploitation attempts. The fix represents a targeted correction that maintains system stability while addressing the specific race condition without broader architectural changes to the multicast subsystem. Organizations should prioritize patching this vulnerability as part of their regular security maintenance procedures, particularly in environments where network configuration changes occur frequently or where systems may be exposed to untrusted network input that could trigger device destruction scenarios.