CVE-2022-48910

What it actually does

Repeated NETDEV_DOWN events without corresponding ipv6_mc_up() calls allocate duplicate entries in idev->mc_tomb, leaking one struct ifmcaddr6 per nontrivial IPv6 multicast group each time the interface or IPv6 state is toggled.

Why it matters to the business

Memory exhaustion on Linux systems using IPv6 multicast can degrade performance, trigger OOM kills, or cause service outages on network-heavy workloads; the issue affects a broad range of kernel versions still in use across servers and appliances.

How an attack unfolds

An attacker with local access joins IPv6 multicast groups (via unprivileged setsockopt or sysctl), then repeatedly toggles the interface state or the disable_ipv6 sysctl to force multiple NETDEV_DOWN events, accumulating leaked ifmcaddr6 objects until memory pressure occurs.

How to fix it

Upgrade the Linux kernel to a version containing commit 9a8736b2da28b24f01707f592ff059b9f90a058c or later; apply the stable backports that enforce the ready-state check before calling ipv6_mc_down().

How to confirm the fix worked

Confirm the running kernel contains the fix commit, reproduce the provided reproducer script and verify that no additional ifmcaddr6 objects accumulate, and monitor slabinfo or kmemleak for the leak pattern after interface state changes.

Typical attack path

1. Obtain local shell or sufficient privileges to run ip and sysctl commands
2. Subscribe to one or more IPv6 multicast groups on a target interface
3. Repeatedly execute ip link set up/down or toggle net.ipv6.conf.*.disable_ipv6
4. Monitor slab or kmalloc usage growth for ifmcaddr6 objects
5. Continue until memory pressure triggers denial of service or instability

How to detect it

Inspect kernel logs for repeated NETDEV_DOWN events on the same interface without matching UP events; monitor slabinfo or /proc/meminfo growth in the size-128 or size-192 caches after interface toggles; review audit logs for sequences of ip-link or sysctl commands altering IPv6 state.

What your security team should do

• Prioritize kernel upgrades on all systems exposing IPv6 multicast or frequent interface changes
• Harden interface configuration to limit unprivileged multicast joins where possible
• Add memory-usage alerts for slab objects related to IPv6 multicast during routine monitoring
• Review and restrict sysctl net.ipv6.conf.*.disable_ipv6 and forwarding settings via configuration management