CVE-2026-63962

What it actually does

This is a Linux kernel memory-corruption flaw in the USB Type-C Port Controller Manager (TCPM) Structured Vendor Defined Message handling path. A malicious or malformed USB-C port partner can send unexpected Discover Modes ACK messages that cause svdm_consume_modes() to write past the end of the altmode_desc[] array. The overwrite can corrupt adjacent fields in the tcpm_port structure, including the partner_altmode[] pointer array, with attacker-influenced SVID/VDO data. Practical outcomes may include kernel crash, USB-C/Power Delivery subsystem instability, denial of service, or potentially more serious kernel memory corruption depending on architecture, memory layout, hardening, and reachable code paths.

Why it matters to the business

Systems that expose USB-C ports using the affected Linux kernel TCPM code can be destabilized by a malicious or faulty connected USB-C device, dock, charger, adapter, or test fixture. The most likely operational impact is local denial of service, such as kernel panic, device reboot, loss of USB-C functionality, or disruption of charging/display/alternate-mode negotiation. Because exploitation requires a malicious physical or directly connected USB-C port partner, broad internet-scale exploitation is unlikely; however, laptops, kiosks, embedded devices, lab equipment, industrial systems, and shared workstations with accessible USB-C ports have higher practical exposure.

How an attack unfolds

An attacker needs the ability to connect or emulate a USB-C Power Delivery port partner to a vulnerable Linux system. After the TCPM code recognizes a partner, the attacker participates in or mimics the normal Structured VDM discovery flow until the kernel's altmode tracking is nearly full. The attacker then sends an additional unsolicited Discover Modes ACK containing more mode VDOs than the remaining array capacity. Because the vulnerable code checks the array bound only before entering the loop, rather than for each VDO processed, the loop writes beyond altmode_desc[]. The overwritten bytes come from attacker-controlled SVID/VDO message content and can corrupt adjacent kernel data structures. Exploitation would typically be performed through a malicious USB-C device, dock, charger, cable emulator, or PD fuzzing tool rather than over the network. No public exploit maturity is indicated, EPSS is low, and the issue is not listed in CISA KEV, but physical-access scenarios and untrusted USB-C peripherals remain relevant.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the TCPM fix moving the altmode_desc[] bounds check inside the per-mode processing loop in svdm_consume_modes(). If exact fixed package versions are provided by a Linux distribution, device vendor, or appliance supplier, apply those packages and reboot into the updated kernel. Where immediate patching is not possible, reduce exposure by restricting physical access to USB-C ports, disabling unused USB-C/USB Power Delivery functionality where supported, preventing untrusted docks/chargers/adapters from being used, applying USB device control policies, and using only trusted power/connection accessories. For embedded or appliance products, obtain a firmware or BSP update from the vendor and verify the running kernel contains the upstream fix or a backport.

How to confirm the fix worked

Confirm the running kernel has the vendor fix or contains the patched TCPM source behavior. Validate by checking the installed and booted kernel package version against the distribution or vendor advisory, not only by checking installed packages. On source-based or custom kernels, inspect drivers/usb/typec/tcpm/tcpm.c and confirm svdm_consume_modes() enforces the ALTMODE_DISCOVERY_MAX bound during each loop iteration before writing to altmode_desc[]. After patching, reboot and verify uname -r reflects the updated kernel. For exposure validation, identify systems with accessible USB-C ports and TCPM support, and check whether the tcpm/typec modules or built-in drivers are present and active. Avoid reproducing the malformed SVDM sequence on production systems unless using controlled hardware and crash-safe test conditions.

Typical attack path

1. Obtain physical access to a vulnerable Linux system or place a malicious USB-C peripheral, dock, charger, adapter, or emulator where it will be connected.
2. Act as a USB-C Power Delivery port partner so the Linux TCPM stack initializes partner state.
3. Send normal or mostly normal SVDM discovery responses to drive the kernel's alternate-mode counter near its maximum.
4. Send an unsolicited Discover Modes ACK containing multiple VDOs after the alternate-mode array is almost full.
5. Trigger out-of-bounds writes in the kernel TCPM data structure.
6. Cause kernel memory corruption, potentially resulting in a crash, reboot, USB-C subsystem malfunction, or further exploitation if memory layout and hardening can be bypassed.

How to detect it

Detection should focus on evidence of local USB-C/Power Delivery abuse and resulting kernel instability. Review kernel logs, persistent journal entries, crash dumps, pstore records, and endpoint telemetry around the time suspicious USB-C devices, docks, chargers, or adapters were connected. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/crash, /sys/fs/pstore, kdump/vmcore records, and EDR telemetry that records device insertion events. Look for kernel oops, panic, KASAN, UBSAN, general protection fault, or slab-out-of-bounds reports with stack traces referencing TCPM, Type-C, SVDM, svdm_consume_modes(), or tcpm_pd_svdm(). Also investigate repeated USB-C negotiation failures, sudden reboots after connecting a peripheral, unexplained loss of charging/display alternate mode, or crashes correlated with specific docks, chargers, adapters, or USB-C PD emulation hardware. There may be no durable host IOC if the attack only causes transient memory corruption or a crash, so correlation between physical device insertion and kernel fault timing is important.

• svdm_consume_modes
• tcpm_pd_svdm
• drivers/usb/typec/tcpm/tcpm.c
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• BUG: unable to handle kernel
• general protection fault
• kernel panic
• Oops:
• tcpm
• typec
• SVDM
• Discover Modes
• /sys/fs/pstore
• /var/crash
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Prioritize patching laptops, shared workstations, kiosks, embedded systems, and operational devices where untrusted users can access USB-C ports.
• Update to a fixed vendor kernel or firmware release and reboot systems so the patched kernel is active.
• Restrict use of untrusted USB-C docks, chargers, adapters, cables, and PD-capable test devices until patching is complete.
• For high-risk physical-access environments, enforce USB/Thunderbolt/Type-C device control policies and consider disabling unused ports or alternate-mode functionality.
• Review recent kernel crash, panic, and USB-C/Power Delivery logs on systems with accessible USB-C ports for signs of anomalous SVDM or TCPM behavior.
• Include USB-C peripherals and docks in hardware trust policies, especially in shared offices, public spaces, labs, manufacturing floors, and travel scenarios.
• For custom kernels or embedded products, verify the patch is backported rather than relying solely on upstream version numbers.