CVE-2026-63959

What it actually does

This Linux kernel flaw affects USB Type-C Power Delivery handling in the TCPM/TCPCI Maxim driver path. A malicious or faulty USB-C/PD partner can send a CRC-valid message whose header claims more Power Delivery data objects than are actually present in the received body. Without validating the advertised object count against the actual received byte count, the kernel may read uninitialized stack memory while processing the malformed frame. The primary impact is local, adjacent physical-bus information disclosure from kernel memory; exploitation requires interaction with a USB-C/PD-capable port or device rather than remote network access.

Why it matters to the business

Systems with affected Linux kernels and relevant USB Type-C controller support could leak small amounts of sensitive kernel memory to a malicious USB-C device, dock, charger, cable, or compromised connected port. The practical risk is highest for laptops, developer workstations, kiosks, shared devices, lab systems, and high-trust environments where untrusted USB-C accessories may be connected. EPSS is low and there is no known KEV listing or public exploit maturity indicated, so this is not currently a mass-exploitation priority, but it should still be addressed through normal kernel update processes because it affects a privileged kernel code path.

How an attack unfolds

An attacker needs physical or very close hardware-level access to a target USB-C port, or control of a device, dock, charger, cable emulator, or USB-C/PD sink/source connected to the target. The attacker sends a crafted USB Power Delivery frame that passes CRC validation but contains an inconsistent length: the message header advertises up to seven data objects while the actual received byte count contains fewer bytes. The vulnerable kernel driver trusts the advertised header count and processes data beyond the received message body, causing reads from uninitialized stack memory. Depending on how the response or processing path exposes that data, the attacker may recover fragments of kernel memory. There is no indication from the supplied intelligence that this vulnerability is being used by named threat actors or ransomware campaigns.

How to fix it

Update to a Linux kernel version that includes the fix adding validation of the Power Delivery header NDO value against RX_BYTE_CNT in the usb typec tcpm/tcpci_maxim code path. If vendor-maintained distributions are used, apply the appropriate kernel security update from the OS or appliance vendor rather than relying only on upstream version numbers. If immediate patching is not possible, reduce exposure by restricting physical access to USB-C ports, avoiding untrusted USB-C chargers/docks/cables/peripherals, disabling unused USB-C/Thunderbolt/USB Power Delivery functionality where operationally feasible, and enforcing device-control policies for high-risk endpoints. Reboot systems after kernel updates so the fixed kernel is actually running.

How to confirm the fix worked

Confirm that systems are running a vendor kernel build containing the tcpci_maxim RX_BYTE_CNT/NDO validation fix. Validate with package inventory, kernel version and changelog review, and vendor advisory mapping for the installed distribution. On Linux endpoints, check the running kernel with `uname -a` and compare it to the vendor-fixed release, then verify the installed kernel package is the active booted kernel after reboot. For exposure assessment, identify systems with USB-C/Type-C controller support and loaded Type-C/TCPCI-related kernel modules, especially `tcpci_maxim`, `tcpm`, `typec`, or vendor-specific USB-C controller drivers. Functional validation can include confirming that malformed USB Power Delivery frames with mismatched advertised data object count and received byte count are rejected rather than processed.

Typical attack path

1. Obtain physical access to the target system's USB-C port or control a connected USB-C/Power Delivery accessory such as a dock, charger, cable emulator, or malicious peripheral.
2. Initiate USB-C Power Delivery communication with the target's Type-C Port Controller path handled by the affected Linux kernel driver.
3. Transmit a CRC-valid Power Delivery message whose header advertises more data objects than are present in the received message body.
4. Trigger the vulnerable parsing path to read beyond the valid received frame into uninitialized stack memory.
5. Capture any protocol response, side effect, or leaked data made available through the USB-C/PD interaction.
6. Repeat crafted exchanges as needed to attempt collection of additional memory fragments.

How to detect it

Retrospective detection is difficult because exploitation occurs over the USB-C Power Delivery control path and may not produce distinctive operating-system logs. Review kernel logs, system journals, endpoint telemetry, and hardware/device-control logs for unusual USB-C or Type-C activity around the time of suspicious physical access, including repeated connect/disconnect events, Power Delivery negotiation failures, Type-C controller errors, or unexpected devices, docks, chargers, or cable emulators. Useful log sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, endpoint device-control logs, EDR USB device inventory, and physical access/control records for high-risk systems. Look for evidence of unknown USB-C accessories attached shortly before sensitive activity, but absence of logs does not rule out exploitation. No named threat actors, campaigns, ransomware use, or public exploitation indicators were provided.

What your security team should do

• Prioritize patching laptops, workstations, kiosks, lab devices, and other Linux systems where untrusted USB-C devices or chargers may be connected.
• Apply vendor-supplied kernel updates and reboot affected systems to ensure the fixed kernel is active.
• Inventory systems with USB-C/Power Delivery support and identify whether relevant Type-C, TCPM, TCPCI, or Maxim controller drivers are present or loadable.
• Temporarily restrict use of untrusted USB-C docks, chargers, cables, and peripherals in sensitive areas until patched.
• For managed endpoints, enforce USB device-control and physical-port security policies where feasible.
• Review kernel and endpoint telemetry for unusual USB-C/Type-C events, repeated device attach/detach activity, or errors around Power Delivery negotiation, while recognizing that successful exploitation may leave minimal logs.
• Treat this as lower urgency than remotely exploitable or KEV-listed vulnerabilities, but include it in regular kernel security maintenance because it affects kernel memory handling.