CVE-2022-48910: net: ipv6: ensure we call ipv6_mc_down() at most once
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: ensure we call ipv6_mc_down() at most once
There are two reasons for addrconf_notify() to be called with NETDEV_DOWN:
either the network device is actually going down, or IPv6 was disabled
on the interface.
If either of them stays down while the other is toggled, we repeatedly
call the code for NETDEV_DOWN, including ipv6_mc_down(), while never
calling the corresponding ipv6_mc_up() in between. This will cause a
new entry in idev->mc_tomb to be allocated for each multicast group
the interface is subscribed to, which in turn leaks one struct ifmcaddr6
per nontrivial multicast group the interface is subscribed to.
The following reproducer will leak at least $n objects:
ip addr add ff2e::4242/32 dev eth0 autojoin
sysctl -w net.ipv6.conf.eth0.disable_ipv6=1
for i in $(seq 1 $n); do
ip link set up eth0; ip link set down eth0
done
Joining groups with IPV6_ADD_MEMBERSHIP (unprivileged) or setting the
sysctl net.ipv6.conf.eth0.forwarding to 1 (=> subscribing to ff02::2)
can also be used to create a nontrivial idev->mc_list, which will the
leak objects with the right up-down-sequence.
Based on both sources for NETDEV_DOWN events the interface IPv6 state
should be considered:
- not ready if the network interface is not ready OR IPv6 is disabled
for it
- ready if the network interface is ready AND IPv6 is enabled for it
The functions ipv6_mc_up() and ipv6_down() should only be run when this
state changes.
Implement this by remembering when the IPv6 state is ready, and only
run ipv6_mc_down() if it actually changed from ready to not ready.
The other direction (not ready -> ready) already works correctly, as:
- the interface notification triggered codepath for NETDEV_UP /
NETDEV_CHANGE returns early if ipv6 is disabled, and
- the disable_ipv6=0 triggered codepath skips fully initializing the
interface as long as addrconf_link_ready(dev) returns false
- calling ipv6_mc_up() repeatedly does not leak anything
Security readout for executives and security teams
Plain-English summary
CVE-2022-48910 is a Linux kernel IPv6 memory leak. Repeated network-interface down handling can allocate multicast cleanup entries without freeing them. Over time, this can consume kernel memory and degrade or disrupt a system. Public sources do not provide a CVSS score and do not show known active exploitation.
Executive priority
Treat as a routine-to-priority Linux kernel maintenance issue, higher for multi-tenant systems or hosts with untrusted local workloads. The business risk is service instability from kernel memory leakage, not data theft based on current sources.
Technical view
The flaw is in Linux IPv6 addrconf NETDEV_DOWN handling. When an interface is down or IPv6 is disabled, repeated transitions can call ipv6_mc_down() multiple times without ipv6_mc_up(), leaking struct ifmcaddr6 entries for subscribed multicast groups. The kernel fix tracks IPv6 ready state and runs multicast down handling only on real ready-to-not-ready transitions.
Likely exposure
Exposure is limited to Linux systems running affected kernel versions with IPv6 interface handling and multicast group subscriptions. The source notes unprivileged IPV6_ADD_MEMBERSHIP can create multicast list entries, but changing interface state or IPv6 settings commonly requires privileges or administrative control.
Exploitation context
The CVE record includes a reproducer concept, but no KEV listing and no cited evidence of active exploitation. Practical abuse appears to require repeated interface or IPv6-state changes plus multicast subscriptions, making denial-of-service through memory leakage the main concern.
Researcher notes
The source describes a state-management bug, not a bounds error. Focus analysis on addrconf_notify(), NETDEV_DOWN paths, ipv6_mc_down(), ipv6_mc_up(), and idev->mc_tomb growth. Evidence is incomplete on exact distribution package status; use vendor advisories for production decisions.
Mitigation direction
Prioritize kernel updates from your Linux distribution or kernel vendor.
Confirm the running kernel includes one of the referenced stable fixes.
If immediate patching is unavailable, review vendor guidance for temporary mitigations.
Restrict unnecessary local administrative access to network interface and IPv6 configuration controls.
Assess whether IPv6 is required on exposed or multi-tenant systems.
Validation and detection
Inventory Linux kernel versions across servers, appliances, and container hosts.
Compare kernels against vendor advisories and the listed upstream stable commits.
Identify systems where IPv6 is enabled on active interfaces.
Review systems with untrusted local users, containers, or workloads using IPv6 multicast.
Monitor for abnormal kernel memory growth on suspected unpatched systems.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2022-48910 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.