CVE-2026-98103 in Linuxinfo

Summary

by MITRE • 09/25/2026

In the Linux kernel, the following vulnerability has been resolved:

igmp: convert struct ip_sf_list to RCU

Commit 23d2b94043ca ("igmp: Add ip_mc_list lock in ip_check_mc_rcu") added spin_lock_bh(&im->lock) to ip_check_mc_rcu() to prevent a use-after-free while iterating im->sources during concurrent deletions.

However, ip_check_mc_rcu() is called from RCU read-side critical sections in packet receive and route lookup fast paths (e.g. __mkroute_output(), ip_route_input_rcu(), and __udp4_lib_rcv()).

When igmpv3_send_cr() or igmpv3_send_report() holds &pmc->lock and calls add_grec() -> igmpv3_newpack() -> ip_route_output_ports(), an XFRM policy matching a multicast destination triggers xfrm_tmpl_resolve_one() -> xfrm4_get_saddr() -> __mkroute_output() -> ip_check_mc_rcu(). 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 ip_sf_list to RCU, mirroring the IPv6 implementation in net/ipv6/mcast.c:

1. Add struct rcu_head to struct ip_sf_list and annotate sf_next, sources, and tomb as __rcu pointers. 2. Use rcu_assign_pointer() and kfree_rcu() for list updates and deletions. 3. Remove spin_lock_bh(&im->lock) from ip_check_mc_rcu() and traverse im->sources locklessly with for_each_psf_rcu(), reading and writing counter fields with READ_ONCE() and WRITE_ONCE().

Note: RCU conversion of /proc/net/mcfilter will be done in a separate patch.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 09/25/2026

The Linux kernel vulnerability addressed involves a deadlock scenario within the Internet Group Management Protocol (IGMP) implementation, specifically affecting IPv4 multicast source filtering operations. The root cause stems from an improper locking strategy introduced to mitigate use-after-free conditions during concurrent deletions of multicast sources. A previous commit added a spin lock, im->lock, around ip_check_mc_rcu() to protect the iteration over the im->sources list. While this measure successfully prevented race conditions related to memory safety, it inadvertently created a circular dependency in locking order that manifests under specific network routing and policy matching scenarios. This issue highlights the complexity of managing synchronization primitives within high-performance kernel paths where multiple locks must be acquired without violating lock ordering rules or causing deadlocks.

The operational impact is triggered when IGMPv3 control messages are processed, specifically during functions like igmpv3_send_cr() or igmpv3_send_report(). These functions hold the pmc->lock and invoke add_grec(), which leads to ip_route_output_ports(). If an XFRM security policy matches a multicast destination address, the kernel executes xfrm_tmpl_resolve_one(), followed by xfrm4_get_saddr() and __mkroute_output(). The final step in this chain is calling ip_check_mc_rcu(), which attempts to acquire im->lock. Since pmc->lock is already held on the same CPU context, this results in a recursive locking warning detected by lockdep or an actual deadlock that can stall network processing for affected systems. This vulnerability affects system stability and availability, particularly under heavy multicast traffic loads combined with IPsec policy configurations.

The resolution involves converting the IPv4 struct ip_sf_list to use Read-Copy-Update (RCU) synchronization mechanisms, aligning it with the existing implementation in the IPv6 stack found in net/ipv6/mcast.c. This architectural change eliminates the need for spin locks during read-side critical sections by allowing lockless traversal of source lists. The fix includes adding an rcu_head structure to ip_sf_list and annotating pointers such as sf_next, sources, and tomb with __rcu attributes to enforce proper RCU semantics. List updates and deletions are managed using rcu_assign_pointer() for safe publication and kfree_rcu() for deferred memory reclamation after all readers have completed their access. This approach ensures that concurrent modifications do not interfere with ongoing reads while maintaining data integrity without the overhead of locking in fast paths.

From a technical perspective, this vulnerability maps to CWE-833 Lock Inconsistency, as it involves incorrect ordering or usage of synchronization primitives leading to deadlock conditions. The operational context aligns with MITRE ATT&CK techniques related to Denial of Service via resource exhaustion or system instability caused by kernel-level deadlocks. By removing the spin lock from ip_check_mc_rcu(), which is frequently called in packet receive and route lookup fast paths, the fix also improves performance by reducing contention on im->lock during high-throughput multicast operations. Developers must ensure that counter fields within these structures are accessed using READ_ONCE() and WRITE_ONCE() macros to prevent compiler optimizations from causing visibility issues across CPUs without explicit locking.

Mitigation strategies for organizations unable to immediately apply kernel updates include disabling IGMPv3 source-specific multicast features if not required, or adjusting XFRM policies to avoid matching multicast destinations that trigger the problematic code path. However, these workarounds may limit network functionality and are not sustainable long-term solutions. The recommended action is to update the Linux kernel to a version containing this fix. System administrators should monitor for lockdep warnings in system logs as an indicator of potential deadlock conditions before applying patches. Future maintenance efforts will extend RCU conversion to /proc/net/mcfilter interfaces, ensuring consistent synchronization mechanisms across all multicast filtering operations within the kernel networking stack.

Responsible

Linux

Reservation

09/25/2026

Disclosure

09/25/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!