A newly published Linux kernel vulnerability lets a USB-C device—anything from a charger to a docking station—write past the end of a kernel data structure, potentially opening the door to memory corruption. CVE-2026-63960, published on July 19, 2026, lives in the Whiskey Cove (WCOVE) Type-C driver responsible for parsing USB Power Delivery messages. The fix is only a few lines of code, but it repairs two distinct mistakes that together create an out-of-bounds write on the kernel stack. While the flaw is not in Windows itself, it demands action from anyone running Linux on hardware with this controller—including dual‑boot machines, dedicated appliances, and systems where USB‑C is passed through to a Linux guest.

How a five‑bit length field broke a 30‑byte buffer

The vulnerable code appears deceptively simple: a loop reads bytes from the controller’s receive FIFO into a struct pd_message that represents an incoming Power Delivery frame. That struct is exactly 30 bytes long—a two‑byte header followed by up to seven four‑byte data objects. The loop count, however, came from a five‑bit field in a hardware status register, meaning it could report as many as 31 bytes. If a malicious partner (a charger, dock, or even a specially crafted cable) sends a 31‑byte frame, the driver writes one byte past the end of the message structure.

The difference between 30 and 31 may sound trivial, but it crosses a strict memory‑safety boundary. The pd_message was allocated on the interrupt‑thread stack, so an overrun can corrupt adjacent stack data. Exactly what gets overwritten depends on the compiler’s layout, the kernel build configuration, and the call chain—variables that differ from system to system and can determine whether the flaw leads to a crash, silent data corruption, or potentially more severe consequences.

The hidden second bug: writing whole integers, not bytes

Even without the length error, the driver had a more subtle problem. It called regmap_read() directly with a byte pointer, but that API is designed to write an unsigned int to its destination. Because the hardware registers are eight bits wide, the upper three bytes of each store are zero. In a normal iteration, later writes overwrite those extra zeros, making the code appear to work in testing. But the last iteration has no subsequent write to mask the overflow: with a 30‑byte report, the final register read already writes three zero bytes past the end of the message buffer.

The CVE description, first reported by the Linux kernel community via the National Vulnerability Database, likens this to a double‑fault: an untrusted external length combined with an API contract violation. The driver trusted data coming from a device register as much as it trusted its own destination buffer, and it treated a register‑map read as though it output a single byte when it actually output a full 32‑bit value.

The patch: two defensive moves

The fix, already merged into mainline and backported to stable kernels, adds two protections:

  • Clamp the copy length. The loop now stops at sizeof(struct pd_message) regardless of what the hardware reports. This makes the maximum write position mechanically obvious and removes any reliance on protocol‑level enforcement that might not exist in hardware.
  • Read into a local integer first. Each FIFO register is now read into a local unsigned int variable; only its low byte is stored into the pd_message buffer. This restores the API’s expected type discipline and guarantees that a store writes exactly one byte.

These changes are small but rigorously correct. They don’t try to validate the USB PD message—that’s left to higher‑level protocol handlers—but they ensure that no matter what arrives in the receive FIFO, the kernel can never corrupt its own memory.

Who’s exposed—and who isn’t

The vulnerable driver (drivers/usb/typec/tcpm/wcove.c) supports a specific Intel‑era USB‑C controller. It’s not present in every Linux system. A machine running Linux that lacks the WCOVE hardware, or that has the driver compiled as a module and never loaded, is not at risk from this particular CVE. The exposure is concentrated in older mobile and embedded designs—tablets, compact laptops, industrial panels—often found in kiosks, point‑of‑sale terminals, and lab equipment.

Affected kernels range from 4.15 up through the latest stable series. The following upstream releases contain the fix:

  • Linux 5.10.259 and later
  • Linux 5.15.210 and later
  • Linux 6.1.176 and later
  • Linux 6.6.143 and later
  • Linux 6.12.93 and later
  • Linux 6.18.35 and later
  • Linux 7.0.12 and later

Organizations that rely on enterprise distributions (Red Hat, SUSE, Ubuntu, etc.) should check their vendor’s security advisory rather than matching upstream version numbers. Many distributions backport fixes without changing the base kernel version string, so a uname -a check alone can be misleading.

Windows users: this is not your kernel, but it is your ecosystem

CVE‑2026‑63960 lives in the Linux kernel, not in Windows. Plugging a USB‑C device into a Windows 11 PC will not trigger this flaw. However, a growing number of Windows users operate mixed environments. If you dual‑boot Windows and Linux on the same hardware, the Linux installation must be patched independently—even though the shared USB‑C port is the same physical connector. Running an unpatched kernel on the Linux side means the vulnerability is present whenever Linux boots.

Windows Subsystem for Linux (WSL) adds a twist. WSL uses a Microsoft‑supplied kernel that is maintained separately from mainline. Standard WSL configurations do not pass USB‑C controller registers into the Linux guest. If you’re using advanced pass‑through features that expose host USB controllers to WSL, you may be bridging an affected Linux driver to real hardware. In those cases, keep your WSL kernel updated through the normal Windows Update and wsl --update channels, and verify which devices are actually exposed to the Linux environment.

For IT managers who oversee both Windows endpoints and Linux appliances, this CVE is a reminder to unify asset inventory. A vulnerability scanner that only looks at broad kernel versions can generate false positives, while a Windows‑centric tool might completely miss small embedded Linux boxes that share the same USB‑C accessory pool.

What to do right now

The primary mitigation is to update the Linux kernel and reboot into the patched version. Because the flaw is in kernel‑space driver code, updating userspace packages alone does not remove the vulnerability. A reboot is essential: until the system boots the new kernel, the old code remains in memory.

Here’s a practical verification sequence:

  1. Identify the running kernel. Use uname -r to see the exact version, then check your distribution’s package changelog for mentions of CVE‑2026‑63960 or the upstream commit IDs (e.g., 3e632098d052, 4af7ad0e6d7a).
  2. Confirm driver presence. Run lsmod | grep wcove or check for the device in lsusb or dmesg output. If the WCOVE driver isn’t loaded, your immediate risk is low—but you should still patch to prevent future risk.
  3. Install the vendor update. Use your distribution’s package manager to fetch the latest kernel package. For example: apt update && apt upgrade linux-image-$(uname -r) (Debian/Ubuntu), dnf update kernel (Fedora), or zypper update kernel-default (openSUSE).
  4. Reboot and re‑validate. After rebooting, confirm the new kernel is active with uname -r. Then re‑check that the WCOVE driver, if loaded, corresponds to the patched code.
  5. Test USB‑C functions. Particularly charging, docking, and display output. The fix should be transparent, but any regression in USB‑C behavior should be reported to the vendor.

If patching cannot happen immediately, limit physical access to USB‑C ports on affected devices. Disconnect unnecessary docks, avoid public charging stations, and treat unknown accessories as untrusted. Disabling the WCOVE driver entirely (e.g., via modprobe -r wcove or kernel command‑line modprobe.blacklist=wcove) is a blunt instrument that may break charging and display output, so test thoroughly before deploying it as a temporary workaround.

A wake‑up call for USB‑C’s control plane

USB‑C has become the one connector to rule them all, but its flexibility also makes Power Delivery a control channel that deserves the same scrutiny as any network protocol. This vulnerability shows that a driver must treat length fields from a connected device as adversarial input, just as a TCP stack would treat a network packet. The fix’s use of sizeof() to define the copy boundary is a textbook lesson: the destination buffer’s size is a compile‑time constant that must govern any copy loop, no matter what the hardware claims.

For the Linux community, CVE‑2026‑63960 is a success story of thorough code review and rapid patching. The original driver carried a FIXME comment specifically questioning whether the hardware enforced the USB PD object‑count limit—a note that made the flaw easier to identify when the report arrived. The patch addresses both root causes without waiting for an exploit proof of concept, and the fixes are available across all maintained stable trees.

For Windows‑focused readers, the takeaway is simpler: keep your Linux deployments updated with the same discipline you apply to Windows Update. Whether it’s a dual‑boot laptop or a fleet of edge devices, the security boundary around a USB‑C port is only as strong as the kernel listening on the other end. Patch now, verify the reboot, and treat every connected cable as potentially hostile.