CVE-2025-21659: netdev: prevent accessing NAPI instances from another namespace
In the Linux kernel, the following vulnerability has been resolved:
netdev: prevent accessing NAPI instances from another namespace
The NAPI IDs were not fully exposed to user space prior to the netlink
API, so they were never namespaced. The netlink API must ensure that
at the very least NAPI instance belongs to the same netns as the owner
of the genl sock.
napi_by_id() can become static now, but it needs to move because of
dev_get_by_napi_id().
Security readout for executives and security teams
Plain-English summary
A Linux kernel networking flaw can let a highly privileged local process cross a network-namespace boundary when using the netlink API to access NAPI networking instances. Successful abuse could alter networking state, disrupt service, or expose limited information. It is not a remote, unauthenticated vulnerability.
Executive priority
Prioritize patch assessment for multi-tenant, containerized, or namespace-heavy Linux environments. Emergency internet-edge action is not indicated because exploitation requires highly privileged local access, but the possible cross-namespace integrity and availability impact warrants timely remediation.
Technical view
NAPI identifiers were not historically namespaced. The newer netlink interface failed to verify that a requested NAPI instance belonged to the network namespace owning the generic-netlink socket. The published CVSS 3.1 score is 8.1, reflecting local access, low complexity, high privileges, changed scope, and potentially high integrity and availability impact.
Likely exposure
Exposure applies to Linux systems running affected kernels where highly privileged local users or workloads can interact with the relevant netlink networking interface. The supplied record identifies versions 6.8, 6.12.10, and 6.13 as affected, but its version metadata is ambiguous and should be confirmed against distribution advisories.
Exploitation context
The attacker requires local access and high privileges; no user interaction is required. Containers or workloads separated by network namespaces may be especially relevant to review. The CVE is not in the supplied KEV data, and the cited sources provide no evidence of active exploitation.
Researcher notes
The security boundary failure is a missing network-namespace ownership check for NAPI lookup through generic netlink. The referenced kernel commits are the authoritative fix evidence supplied. Exact introduction and fixed-version ranges cannot be established confidently from this bundle because the affected-version entries include ambiguous values and duplicate commit metadata.
Mitigation direction
Apply a distribution-supported kernel containing the referenced namespace-validation fix.
Confirm fixed package versions through the Linux distribution or appliance vendor.
Restrict unnecessary privileged local and container access while updates are pending.
Reboot into the updated kernel after installation, following operational change controls.
Validation and detection
Record the running kernel version on every potentially exposed Linux host.
Compare versions with vendor advisories and the referenced stable-kernel fixes.
Verify systems booted into the updated kernel, not merely installed its package.
Review privileged workloads using network namespaces and netlink networking interfaces.
Monitor vendor guidance because the supplied affected-version data is incomplete.
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-2025-21659 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.
1CVSS vectors
3Timeline events
0ADP providers
3Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.