CVE-2026-64423

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 devices 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: 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

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

Weakness

The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory “belongs” to the code that operates on the new pointer.

Affected Software

Potential Mitigations

References

• https://git.kernel.org/stable/c/2ca18df1c2611f70eb3eb487e02ae85eb703b284
• https://git.kernel.org/stable/c/412ba7def06ffe974ba9a1d862b022362c54ffa5
• https://git.kernel.org/stable/c/5f42729d74bd6c61306d864423290d92962de4e1
• https://git.kernel.org/stable/c/76d030ac95e17f91d69a595f17ebc5979700cf9a
• https://git.kernel.org/stable/c/7993211bde166471dffac074dc965489f86531f8
• https://git.kernel.org/stable/c/8820b530cb2388503d7418228d03ba074bf7a03e
• https://git.kernel.org/stable/c/c6cb5f8ebe1c1a78710c19f102db9fe48b9e6ba9
• https://git.kernel.org/stable/c/f91883031e5a62877a29ce139442973cbea769f1
• https://cert-portal.siemens.com/productcert/html/ssa-019113.html