CVE-2026-98103

CVE CVE-2026-98103EUVD EUVD-2026-86934Published 2026-09-25T10:35:53.000Z

What the advisory describes

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.

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux 78967749984cf3614de346c90f3e259ff8272735; patch: 7.2.7; 5.14.3 <5.15; 4.19.207 <4.20; 23d2b94043ca8835bd1e67749020e839f396a1c2 <e3206419bdb04e2087d8cc6be324df8639b3fac5; d84708451d9041dff8a81e3718f821f12d2eb6c5; patch: 7.3-rc2; 4.4.284 <4.5; 4.9.283 <4.10; d1a3c6d5925a8d00a32c5ef2d674dd9c0ce89c95; 4768973dffed4d0126854514335ed4fe87bec1ab; 5.10.64 <5.11; 5.15; ddd7e8b7b84836c584a284b98ca9bd7a348a0558; b24065948ae6c48c9e20891f8cfe9850f1d748be; 961447ff60291b91e27d5c32fa549c1411ad3b70; 23d2b94043ca8835bd1e67749020e839f396a1c2 <d3011d1f293478c730aa0870490afa145c37600e; patch: 6.12.111; 5.4.145 <5.5; patch: 0; 5.13.16 <5.14; patch: 6.18.53; 23d2b94043ca8835bd1e67749020e839f396a1c2 <2987ee196c88dbde0463dc87d5fb209c684e34a2; 23d2b94043ca8835bd1e67749020e839f396a1c2 <f5182dfad54277267a8cb0c004a9cd4cf35aeebb; e9924c4204ede999b0515fd31a370a1e27f676bc; 4.14.247 <4.15

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.