CVE-2026-97939: ipmr: account multicast table and route memory

Published Sep 25, 2026
·
Updated

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

1 affected component
Linux Linux kernel

Event History

Sep 25, 2026
CVE Published
via MITRE·10:22 AM
Data Sourced
via MITRE·10:22 AM
Description
Data Sourced
via NVD·11:17 AM
Description

Frequently Asked Questions

1

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.

2

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.

3

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.

4

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203