LiveActive security incident?Get immediate response
CVE Record

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

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysismoderate

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.
Prepared
Confidence
medium
Sources
10

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.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

0CVSS vectors
3Timeline events
1ADP providers
9Source links

SSVC decision data

CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: partial

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

CISA-ADPCISA ADP Vulnrichment
other:ssvc
Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux3ce62a84d53cd3d3cc5377bbf339e9b08ddf9c36, 3ce62a84d53cd3d3cc5377bbf339e9b08ddf9c36, 3ce62a84d53cd3d3cc5377bbf339e9b08ddf9c36, 3ce62a84d53cd3d3cc5377bbf339e9b08ddf9c36, 3ce62a84d53cd3d3cc5377bbf339e9b08ddf9c36, 3ce62a84d53cd3d3cc5377bbf339e9b08ddf9c36, 3ce62a84d53cd3d3cc5377bbf339e9b08ddf9c36, 3ce62a84d53cd3d3cc5377bbf339e9b08ddf9c36unaffected
LinuxLinux3.18, 0, 4.9.313, 4.14.278, 4.19.323, 5.4.193, 5.10.104, 5.15.27, 5.16.13, 5.17affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.