CVE-2026-98101: ipv6: mcast: use copy-on-write RCU updates in ip6_mc_source()
In the Linux kernel, the following vulnerability has been resolved:
ipv6: mcast: use copy-on-write RCU updates in ip6mcsource()
pmc->sflist is read locklessly under rcureadlock() by inet6mccheck() during packet reception in the UDP and RAW multicast receive paths.
ip6mcsource() mutated psl->sladdr and psl->slcount in-place when adding or removing a source filter. Additionally, when expanding the filter buffer, newpsl was published via rcuassignpointer() before writing the new source into the array.
Because 16-byte struct in6addr writes are not atomic and array shifting is not synchronized with RCU readers, concurrent readers in inet6mccheck() could read torn IPv6 addresses or observe duplicated/missed source entries.
Fix this by switching ip6mcsource() to copy-on-write RCU updates: allocate and fully populate newpsl before publishing it via rcuassignpointer(), and reclaim the old filter via kfreercu(), matching ip6mcmsfilter().
Also remove the now unused IP6SFBLOCK macro.
Affected Software
Event History
Frequently Asked Questions
What systems are exposed to this race condition?
Systems using the Linux kernel IPv6 multicast source-filter functionality are exposed when source filters are added or removed concurrently with UDP or RAW multicast packet reception. The affected read path is inet6_mc_check(), which reads the filter list without locking under RCU.
What conditions are required to trigger it?
The race requires concurrent modification of an IPv6 multicast source filter through ip6_mc_source() and packet reception on the UDP or RAW multicast receive paths. The issue arises because readers can access the filter list while source addresses or list entries are being changed.
What can an affected system observe?
Concurrent readers may see torn IPv6 addresses because in6_addr writes are 16 bytes and not atomic. They may also observe duplicate source entries or miss entries while the source-filter array is shifted or expanded.
How is the issue fixed?
The fix changes source-filter updates to copy-on-write RCU updates: a replacement filter list is fully populated before it is published to readers. The previous list is then reclaimed with kfree_rcu(), preventing readers from accessing partially modified data.