CVE-2026-63960

What it actually does

This is a Linux kernel stack-based buffer overflow in the USB Type-C Whiskey Cove/WCOVE driver receive path. The vulnerable function copies USB Power Delivery receive FIFO data into a fixed-size `struct pd_message` without safely bounding the copy and also passes a byte pointer to `regmap_read()`, which writes a full unsigned integer. A malicious or malformed USB-C Power Delivery partner can cause the driver to write beyond the destination structure on the IRQ thread stack. The most likely impact is kernel memory corruption leading to a crash or denial of service, though kernel stack corruption bugs can sometimes be exploitable for privilege escalation or code execution depending on architecture, compiler hardening, stack layout, and reachable overwrite control.

Why it matters to the business

Systems using the affected Linux kernel driver may be crashed or destabilized by a malicious USB-C device or port partner. In practical terms, this is most relevant to laptops, tablets, embedded systems, kiosks, industrial devices, and other endpoints where untrusted USB-C devices can be physically connected. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and currently has low EPSS probability, but it should still be remediated during normal kernel maintenance because exploitation can affect system availability and potentially device trust boundaries.

How an attack unfolds

An attacker needs the ability to act as, or connect, a malicious USB-C Power Delivery partner to a vulnerable system using the WCOVE Type-C driver. The malicious device transmits a crafted Power Delivery frame whose received byte count reaches the edge case handled incorrectly by the driver. When the kernel interrupt handler processes the receive FIFO, the vulnerable copy routine writes past the end of the stack-allocated Power Delivery message buffer. This corrupts adjacent stack memory in kernel context. Depending on the resulting corruption, the system may panic, lock up, reset, or in a more advanced scenario allow further exploitation of kernel memory corruption protections.

How to fix it

Upgrade to a Linux kernel build that includes the WCOVE Type-C fix: the receive loop must be clamped to `sizeof(struct pd_message)` and each register value must be read into a local variable before copying only the low byte into the message buffer. If vendor kernel packages are used, apply the security update from the operating system, device, or appliance vendor once available. Where immediate patching is not possible, reduce exposure by preventing untrusted physical access to USB-C ports, disabling unused USB-C/Type-C functionality where operationally acceptable, and using device control policies to restrict unknown USB-C peripherals. For embedded or custom kernels, backport the upstream patch to all maintained kernel branches that include the WCOVE Type-C driver.

How to confirm the fix worked

Confirm the running kernel includes the corrected WCOVE receive-buffer implementation by checking the vendor advisory, package changelog, or kernel source for the fix that clamps reads to `sizeof(struct pd_message)` and avoids passing `msg + i` directly to `regmap_read()`. Validate that all booted kernels, fallback kernels, golden images, and embedded firmware images have been updated, not just installed package repositories. On representative hardware, test USB-C Power Delivery functionality after patching to ensure normal charging, role negotiation, and device detection still work. Exposure can be assessed by inventorying systems with the WCOVE Type-C driver present or loaded and by identifying devices where untrusted USB-C connections are possible.

Typical attack path

1. Identify a target device running a vulnerable Linux kernel with the WCOVE USB Type-C driver enabled and reachable through a USB-C port.
2. Connect or emulate a malicious USB-C Power Delivery partner to the target system.
3. Send a crafted USB Power Delivery frame with a receive byte count that triggers the unsafe copy behavior in the WCOVE receive path.
4. Cause the kernel IRQ thread to process the malformed receive FIFO data.
5. Trigger kernel stack corruption, resulting in a crash, reboot, denial of service, or potentially further memory-corruption exploitation.

How to detect it

Look for evidence of kernel instability or memory corruption correlated with USB-C or Type-C Power Delivery activity. Useful sources include kernel logs, system journal logs, crash dumps, pstore/ramoops records, kdump/vmcore artifacts, endpoint telemetry, and physical access/device-control logs showing USB-C device connection events. Because exploitation occurs in kernel interrupt context and may only produce a crash, there may be no high-level application logs. Investigate kernel panics, general protection faults, stack corruption warnings, KASAN reports, or spontaneous reboots that occur immediately after USB-C cable, charger, dock, or peripheral connection. If crash dumps are available, inspect call traces for WCOVE Type-C functions such as `wcove_typec_irq()` or `wcove_read_rx_buffer()` and for faults in the USB Type-C/Power Delivery receive path. Treat repeated crashes triggered by the same USB-C accessory, dock, charger, or test device as suspicious and preserve the device for analysis.

• wcove_read_rx_buffer
• wcove_typec_irq
• typec_wcove
• usb: typec: wcove
• KASAN: stack-out-of-bounds
• BUG: stack guard page was hit
• kernel stack overflow
• Kernel panic - not syncing
• general protection fault
• Oops:
• pstore
• ramoops
• vmcore

What your security team should do

• Prioritize patching laptops, tablets, kiosks, embedded systems, and physically accessible devices that expose USB-C ports and run affected Linux kernels.
• Inventory systems for the WCOVE Type-C driver and confirm whether the vulnerable code is present in the running kernel, firmware image, or vendor kernel branch.
• Apply vendor kernel updates or backport the upstream fix into custom kernels; ensure the fixed kernel is actually booted after maintenance.
• Restrict physical access to USB-C ports on sensitive systems until patching is complete, especially in public, shared, or high-risk locations.
• Monitor kernel logs for crashes or memory-corruption symptoms following USB-C device connection events.
• If unexplained kernel panics coincide with USB-C activity, preserve logs and crash dumps for forensic review before reimaging or reboot cycling devices.