The newly published CVE closes a gap left by an earlier p54 security fix. The National Vulnerability Database record describes the vulnerable routine,
p54_rx_eeprom_readback(), as validating the length advertised by the device without first proving that the received socket buffer actually contains that many bytes. Linux wireless maintainers merged the underlying fix into the networking tree on July 10, 2026, as part of a broader wireless robustness update focused on malformed frames and small out-of-bounds reads.
The practical implication is narrow but clear: this is not an over-the-air Wi‑Fi attack against ordinary modern adapters. It is a malicious-device attack path against systems where the p54 driver is present and a hostile USB peripheral can be connected or passed through. That still makes it relevant to Linux laptops, test benches, thin clients, embedded equipment, USB-over-IP deployments, lab systems, and virtual machines with USB passthrough.
The Earlier Fix Did Not Check the Actual Frame
This CVE is notable because it is the second security repair in the same function, and the prior repair addressed a different boundary.
In 2025, upstream Linux fixed CVE-2025-38348, which prevented a p54 device from declaring an oversized EEPROM payload and overflowing the driver’s destination buffer. That patch stopped trusting the device-provided length as the copy size. Instead, the driver retained the expected EEPROM slice size in
priv->eeprom_slice_size, rejected a mismatched advertised length, and copied only that known amount.
That was a meaningful correction, but it created a false sense that the copy was fully bounded. A fixed destination length does not establish that the source contains that many bytes.
CVE-2026-64571 covers that remaining source-side failure. A hostile device can claim that its EEPROM response has exactly the expected length while physically delivering a shorter USB frame. The pre-fix driver accepts the matching length field, then calls
memcpy()for
priv->eeprom_slice_sizebytes. If the packet buffer ends earlier, the kernel reads beyond the end of the
sk_buff.
The upstream patch adds the missing comparison: before copying, it checks whether the end of either version of the EEPROM payload would fall beyond
skb_tail_pointer(skb). If it would, the driver discards the response.
That is a small code change, but it closes the condition that actually separates “the length field says this is safe” from “the memory buffer is safe to read.”
What an Attacker Can Trigger
The CVE description includes a Kernel AddressSanitizer report showing a slab out-of-bounds read in the p54 receive path. In the reported case, the kernel attempted to read 1,016 bytes from a packet buffer allocated at 704 bytes, with the invalid read occurring in interrupt context after a USB receive callback.
The demonstrated effect is a kernel memory safety violation. On hardened debug builds, that can surface as a KASAN report and a crash. On production systems, outcomes can range from a kernel warning or denial of service to unintended disclosure of adjacent heap data, depending on allocator behavior, kernel configuration, and how the affected code is reached.
The public record does not establish reliable privilege escalation or code execution from this issue. It also does not list active exploitation, a CVSS score, a CWE classification, or a public proof-of-concept as of August 9, 2026. NVD has published the record but has not yet completed severity enrichment.
That absence should not be mistaken for a clean bill of health. The attack requires control of a physical or virtual USB device, which sharply limits exposure compared with a remotely reachable kernel flaw. But USB is routinely treated as a hostile-input boundary in enterprise environments precisely because untrusted peripherals, docking stations, device emulators, redirected USB sessions, and passthrough can all cross it.
The Affected Version Record Is More Useful Than the CVE Score
The Linux CNA’s affected-version data identifies the p54 source file,
drivers/net/wireless/intersil/p54/txrx.c, and says the affected code dates back to Linux 2.6.28. The listed fixed upstream maintenance releases are Linux 6.6.148, 6.12.101, 6.18.42, 7.1.6, and 7.2-rc4.
In operational terms, that means the vulnerable code remained in long-lived kernel lines for years and was repaired through stable backports rather than only in the newest development branch. Administrators should not use “we run an older LTS kernel” as a reason to dismiss it. They should verify the exact distribution kernel package and its backport status.
The version data also exposes an administrative trap common to kernel CVEs: an upstream version number is not the same thing as a distribution’s package version. Red Hat, Canonical, SUSE, Debian, VMware, cloud-image publishers, appliance vendors, and embedded Linux suppliers frequently backport narrowly scoped fixes while retaining an older-looking base version. Conversely, a kernel whose version appears newer may be custom-built or missing a downstream security update.
Use the vendor’s kernel advisory and package changelog as the primary answer for an installed distribution kernel. For custom kernels, compare the source tree against the upstream p54 fix that adds
skb_tail_pointer()checks in
p54_rx_eeprom_readback().
p54 Exposure Depends on the Module, Not Merely the Kernel Version
The p54 code serves older Intersil Prism54-family hardware and is usually encountered as modules such as
p54common,
p54pci,
p54spi, or
p54usb. The CVE’s supplied crash path runs through
p54u_rx_cb()in
p54usb.c, so USB-attached p54 devices are the most direct concern described by the technical record.
A vulnerable source file in a vendor’s kernel tree does not automatically mean a running host is exposed. The driver must be included in the kernel configuration, installed as a module or compiled into the image, and able to bind to hardware or a device impersonating that hardware. Systems with no p54 module cannot exercise this specific bug.
For an initial estate check, administrators can use the following commands on representative Linux hosts:
uname -r
modinfo p54common
modinfo p54usb
find /lib/modules/$(uname -r) -iname '*p54*'
lsmod | grep -E 'p54(common|usb|pci|spi)'A missing
p54commonor transport-specific p54 module substantially reduces the immediate concern for that host. A module being present does not prove it is loaded, but it does mean a locally connected compatible or impersonating device may be able to activate the code path.
On managed systems where the legacy hardware is not required, blocking the module is a reasonable temporary control while kernel packages are being updated. A module blacklist can reduce exposure, but it is not a substitute for applying the fixed kernel: systems may have the driver built into the kernel, require it for existing hardware, or reintroduce it through a different image configuration.
Windows Environments Are Indirectly Affected
CVE-2026-64571 is a Linux kernel vulnerability, not a Windows kernel vulnerability. A standard Windows 10 or Windows 11 installation does not use the Linux p54 driver and is not remediated by Windows Update.
Windows-focused administrators should nevertheless account for Linux kernels operating alongside Windows:
- WSL 2 distributions run a Linux kernel, although the p54 driver’s presence depends on Microsoft’s kernel configuration and any custom kernel image in use.
- Hyper-V, VMware Workstation, VirtualBox, and development stacks can expose USB devices to Linux guests through passthrough.
- Azure Linux, Ubuntu, Debian, Kali, security-testing images, recovery media, and appliance VMs may carry separate kernels with different configurations and patch states.
- Corporate USB redirection tools can turn a device connected to one endpoint into a peripheral presented to another machine or virtual machine.
The key test in these cases is artifact-specific: inspect the actual Linux guest or WSL kernel module tree rather than assuming that a Windows host’s patch status says anything about the guest’s kernel.
No Microsoft product advisory or Windows-specific mitigation appears in the newly published CVE record. No independent outlet has yet reported product-level impact for WSL, Azure Linux, or other Microsoft-distributed Linux artifacts. Those products should therefore be treated as unverified, not automatically affected.
Patch the Kernel, Then Remove an Unneeded Driver
The correct remediation is installation of a vendor kernel package that incorporates the upstream validation fix. The upstream change causes malformed EEPROM responses to be rejected before the fixed-size copy takes place; it does not rely on USB policy or a userspace daemon to catch the attack.
For organizations unable to patch immediately, the best interim measure is to prevent untrusted USB devices from reaching potentially affected Linux systems and to blacklist p54 modules where no dependent hardware exists. Security teams should pay special attention to engineering workstations, device-testing infrastructure, shared lab hosts, kiosks, and virtual machine platforms that permit USB passthrough.
The deeper lesson in CVE-2026-64571 is less exotic than the driver’s age suggests. The 2025 p54 patch stopped an attacker from choosing the copy length. The 2026 patch stops an attacker from lying about whether the promised bytes arrived at all. Systems that received only the first repair remain exposed until their kernel includes the second.