The failure sits in
net/ipv6/ndisc.c, in handling for IPv6 Neighbor Advertisements. According to the Linux kernel CVE announcement and the NVD record,
ndisc_recv_na()has already obtained and checked the interface’s IPv6 configuration object,
inet6_dev, when it calls
accept_untracked_na(). That helper then fetches the same pointer a second time and immediately reads
accept_untracked_nawithout checking whether the second lookup returned
NULL.
That second read is the entire vulnerability. The two accesses occur within one RCU read-side critical section, which protects the original object’s lifetime, but does not promise that
dev->ip6_ptrwill remain populated. A concurrent
addrconf_ifdown()can clear the pointer between the first lookup and the redundant second lookup. The result is a kernel NULL-pointer dereference in the IPv6 receive path and an oops.
The Trigger Requires Local Namespace Control, Not a Hostile Internet Packet Alone
The public record specifically says the bug is reachable by an unprivileged user through a network namespace. That makes it materially different from a conventional network-facing kernel flaw where any remote system that can send a packet is the threat actor.
A successful trigger requires control over the local networking environment: IPv6 Neighbor Advertisement processing must coincide with interface IPv6 shutdown. The disclosed reproducer condition involves lowering an interface MTU below IPv6’s minimum MTU, which invokes
addrconf_ifdown()by a path that lacks the ordering used during ordinary device unregister. In other words, the crash depends on a race created from inside the machine, or from a sufficiently empowered container-like workload, rather than merely delivering malformed traffic to an exposed IPv6 service.
This distinction is operationally important for server operators. Systems that disable unprivileged user namespaces, tightly restrict container capabilities, or do not permit tenants to manipulate network interfaces have a smaller practical attack surface than multi-tenant hosts that hand out network namespaces freely. It is still a kernel crash condition, and a crash of a shared host is enough to become a security incident even when no privilege escalation has been demonstrated.
The name
accept_untracked_nacan also send administrators in the wrong direction. It is a kernel IPv6 configuration setting governing acceptance of Neighbor Advertisements for addresses absent from the neighbor cache. But the crash comes from reading the setting through a pointer that may have disappeared; disabling or leaving that setting at its default does not repair the unsafe dereference. The remediation is a kernel update, not a sysctl adjustment.
The Patch Removes a Second Lookup Instead of Adding Another Check
The upstream correction is compact but meaningful: the caller passes its already validated
inet6_devinto
accept_untracked_na()rather than having the helper look up
dev->ip6_ptragain. Because the original object remains alive for the duration of the same RCU read-side section, it is safe to use even after the device’s pointer has been cleared.
That design choice closes the race without turning the helper into another conditional path with an ambiguous failure mode. A simple
NULLcheck on the second lookup would prevent the immediate oops, but it would leave two potentially inconsistent reads of state in an already timing-sensitive receive path. Passing the existing validated object makes the code match the lifetime guarantee RCU was already providing.
The affected code originated with commit
aaa5f515b16b, which the kernel CVE team associates with Linux 6.0. That dates the exposure more precisely than a generic “all Linux systems” advisory: kernels from the 5.10 era can be outside the affected code path, while long-lived deployments on 6.1, 6.6, 6.12 and later lines need their distribution’s backport status checked.
NVD has not yet assigned CVSS v3 or CVSS v4 metrics to CVE-2026-64542. Administrators should resist translating that blank field into “low severity.” The public evidence supports a denial-of-service assessment, but it does not establish arbitrary code execution, information disclosure, or privilege escalation. The absence of a score is an unfinished enrichment process, not a risk rating.
Stable-Kernel Fixes Have Arrived Unevenly
The Linux kernel CVE announcement published on July 27 listed fixes in Linux 6.12.97, 6.18.40, 7.1.5, and the then-new 7.2-rc1. The NVD record was subsequently updated on August 3 to add a fifth stable reference for Linux 6.6.148. That later addition matters for enterprise and appliance deployments, because 6.6 is a widely used long-term support branch and was absent from the original announcement’s fixed-version list.
For kernel trees that correspond directly to upstream stable releases, the practical fixed baselines are:
- Linux 6.6.148 includes the backported fix.
- Linux 6.12.97 includes the backported fix.
- Linux 6.18.40 includes the backported fix.
- Linux 7.1.5 includes the backported fix.
- Linux 7.2-rc1 contains the original upstream change.
Those versions are useful reference points, but they are not a universal package-level answer. Enterprise distributions routinely backport individual security fixes into kernels whose visible version is older than the upstream version where a bug first appeared. Conversely, a distribution package based on a nominally new-enough branch may still be vulnerable until its vendor publishes the patched build. Kernel release numbers alone are a poor substitute for reading the vendor’s advisory or package changelog.
The Linux CVE team explicitly advises deploying the latest distribution kernel rather than cherry-picking this one patch. That is the right operational advice here. Networking and RCU changes are deeply coupled to adjacent fixes, and a hand-applied patch creates an audit burden while bypassing the kernel package testing your vendor actually supports.
Debian and Ubuntu Show Why Package Status Beats Branch Names
Distribution tracking already demonstrates the difference between upstream lineage and installed-package status. Debian’s security tracker marks Debian 11 “bullseye,” with its 5.10-based kernel, as not affected because the vulnerable code is not present. Debian 12 “bookworm” remains listed as vulnerable in its normal 6.1 package stream, while Debian’s separate
linux-6.12package for bookworm has a fixed build,
6.12.100-1~deb12u1.
Debian’s current tracker also records patched packages for newer releases, including
6.12.101-1in trixie security,
7.1.6-1in forky, and
7.1.7-1in sid. Those package identifiers are more useful to a Debian administrator than the broad statement that the issue began in Linux 6.0.
Ubuntu’s tracker assigns the issue a Medium priority. It marks Ubuntu 22.04 LTS Jammy’s standard kernel as not affected, while Ubuntu 24.04 LTS Noble’s standard kernel and relevant newer HWE kernel packages remain vulnerable as of its August 7 update. Ubuntu 26.04 LTS Resolute is also listed as vulnerable. Canonical’s page names the upstream fix but does not yet list a fixed Ubuntu kernel package for those vulnerable entries.
The takeaway is straightforward: do not infer that every older distribution kernel is exposed, and do not assume a current distribution release is protected simply because upstream fixed a newer stable branch. Check the installed package against the vendor’s live status page, then reboot into the patched kernel once it lands.
What Windows and WSL Administrators Should Check
Windows itself is not affected by this Linux kernel CVE. The relevant Windows-adjacent case is WSL 2, which runs a real Linux kernel managed through the Windows Subsystem for Linux stack. A WSL distribution’s user-space release label is not enough to answer whether it is exposed; the relevant version is the running WSL kernel and any Microsoft backports in that kernel package.
No Microsoft advisory or WSL-specific package status for CVE-2026-64542 was identified in the public records reviewed here. That means WSL users should not assume either exposure or immunity based solely on the upstream version ranges. Administrators who use WSL 2 for container workloads, developer environments, or networking tests should apply current Windows and WSL updates, verify the running kernel with
uname -rinside WSL, and watch for a Microsoft package advisory or changelog that explicitly maps its kernel build to this CVE.
For Linux hosts, the immediate work is less dramatic but more urgent: identify machines running kernels derived from 6.0 or later, prioritize systems that permit untrusted users or containers to create network namespaces, install the vendor-provided kernel update, and reboot. CVE-2026-64542 is a narrow race, but on a shared host a reliable kernel oops is still a tenant-controlled outage.
References
- Primary source: NVD / Linux Kernel
Published: August 9, 2026 at 8:41 AM UTC
Loading…
nvd.nist.gov - Security advisory: MSRC
Published: August 9, 2026 at 8:41 AM UTC
Original feed URL
Loading…
msrc.microsoft.com - Related coverage: vulnerability.circl.lu
Loading…
vulnerability.circl.lu - Related coverage: cert.europa.eu
- Related coverage: security-tracker.debian.org
Loading…
security-tracker.debian.org