CVE-2026-97939: ipmr: account multicast table and route memory
In the Linux kernel, the following vulnerability has been resolved:
ipmr: account multicast table and route memory
A netadmin in a user+net namespace can create many IPv4 and IPv6 multicast routing tables with MRTTABLE and MRT6TABLE. Each unseen id allocates an mrtable via the shared mrtablealloc(), links it into the per-net list, and leaves it until netns teardown. Those objects were not charged to memcg, so the host unreclaimable slab grows with the table count.
Account mrtable allocations with GFPKERNELACCOUNT and mark the IPv4/IPv6 MFC caches SLABACCOUNT. This matches the established handling of IP addresses, routes and alternate interface names.
Unresolved MFC entries are still allocated from softIRQ with GFPATOMIC and are not charged. They expire after 10 seconds and are bounded by the socket receive queue; see commit 0079ad8e8dc3 ("ipmr: remove hard code cacheresolvequeuelen limit").
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.7-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.10.273 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.112 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.53 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.7 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
Who can trigger the memory growth?
A process with network-administration privileges in a user and network namespace can create multicast routing tables using MRT_TABLE or MRT6_TABLE with previously unseen IDs. This can create many IPv4 and IPv6 multicast routing table objects.
What memory is affected by the fix?
The fix accounts multicast routing table allocations to the memory cgroup and marks the IPv4 and IPv6 multicast forwarding cache allocations as SLAB_ACCOUNT. Before the fix, routing table objects could increase host unreclaimable slab memory without memcg charging.
What remains unaccounted after this change?
Unresolved multicast forwarding cache entries are still allocated in softirq context with GFP_ATOMIC and are not memcg-charged. They expire after 10 seconds and are bounded by the socket receive queue.
What can limit the impact if patching is not immediately possible?
The multicast routing table objects remain allocated until the network namespace is torn down. Tearing down the affected network namespace releases those objects.