CVE-2026-98103: igmp: convert struct ip_sf_list to RCU
In the Linux kernel, the following vulnerability has been resolved:
igmp: convert struct ipsflist to RCU
Commit 23d2b94043ca ("igmp: Add ipmclist lock in ipcheckmcrcu") added spinlockbh(&im->lock) to ipcheckmcrcu() to prevent a use-after-free while iterating im->sources during concurrent deletions.
However, ipcheckmcrcu() is called from RCU read-side critical sections in packet receive and route lookup fast paths (e.g. mkrouteoutput(), iprouteinputrcu(), and udp4librcv()).
When igmpv3sendcr() or igmpv3sendreport() holds &pmc->lock and calls addgrec() -> igmpv3newpack() -> iprouteoutputports(), an XFRM policy matching a multicast destination triggers xfrmtmplresolveone() -> xfrm4getsaddr() -> mkrouteoutput() -> ipcheckmcrcu(). This attempts to acquire &im->lock while &pmc->lock is already held on the same CPU, triggering a lockdep recursive locking warning / deadlock.
Fix this by converting IPv4 struct ipsflist to RCU, mirroring the IPv6 implementation in net/ipv6/mcast.c:
1. Add struct rcuhead to struct ipsflist and annotate sfnext, sources, and tomb as rcu pointers. 2. Use rcuassignpointer() and kfreercu() for list updates and deletions. 3. Remove spinlockbh(&im->lock) from ipcheckmcrcu() and traverse im->sources locklessly with foreachpsfrcu(), reading and writing counter fields with READONCE() and WRITEONCE().
Note: RCU conversion of /proc/net/mcfilter will be done in a separate patch.
Affected Software
Event History
Frequently Asked Questions
What conditions are involved in triggering the locking problem?
The described path requires IGMPv3 report processing to hold pmc->lock and an XFRM policy that matches a multicast destination. Route resolution can then enter ip_check_mc_rcu() from an RCU read-side critical section and attempt to acquire im->lock recursively on the same CPU.
How might an affected system present this issue?
The documented symptom is a lockdep recursive-locking warning or a deadlock. The underlying code was also intended to prevent a use-after-free while iterating multicast source entries during concurrent deletions.
Which systems are in scope based on the available information?
The issue concerns the Linux kernel's IPv4 IGMP multicast-source handling, particularly receive and route-lookup fast paths such as __mkroute_output(), ip_route_input_rcu(), and __udp4_lib_rcv(). The available data does not identify specific kernel versions or state whether a default configuration is affected.