CVE-2026-64330

What it actually does

This Linux kernel flaw is an out-of-bounds read in the USB Type-C Port Controller Manager (TCPM) Structured Vendor Defined Message (SVDM) handling path. During USB-C Power Delivery alternate-mode discovery, the kernel reads an SVID array using an unvalidated index. A malicious or malformed USB-C/USB-PD partner device can drive the index beyond the valid SVID list and cause the kernel to read adjacent fields inside the same TCPM data structure. Because some adjacent fields are influenced by partner-supplied discovery-mode data, the attacker can cause the kernel to register a partner-chosen alternate-mode SVID. The currently described impact is incorrect kernel state/metadata registration and out-of-bounds memory access in the Type-C subsystem; there is no public evidence of remote code execution, privilege escalation, or broad internet-exploitable attack paths.

Why it matters to the business

Systems with vulnerable Linux kernels and exposed USB-C ports may mishandle malicious USB-C/Power Delivery devices. The most realistic risk is from physical access, malicious docks, chargers, cables, adapters, peripherals, or supply-chain hardware that interact with USB-C alternate-mode negotiation. Operational consequences may include unstable USB-C behavior, incorrect alternate-mode registration, device malfunction, kernel warnings or crashes depending on build/runtime hardening, and increased risk in environments where untrusted peripherals are commonly connected. The low EPSS score and absence from CISA KEV indicate no known broad exploitation at this time, but endpoint fleets, kiosks, labs, shared workstations, and high-trust workstations with accessible USB-C ports should still prioritize kernel updates as part of routine patching.

How an attack unfolds

An attacker needs the ability to present a crafted USB-C/USB Power Delivery partner to a vulnerable Linux system, such as through a malicious USB-C peripheral, dock, charger, adapter, cable, or test device. When the host performs Type-C alternate-mode discovery, the malicious partner sends crafted SVDM Discovery Identity/SVID/Modes responses. By manipulating the discovery sequence so the internal SVID index advances beyond the valid SVID array, the vulnerable kernel reads outside the intended SVID list and into adjacent TCPM mode data. Because some adjacent data contains partner-supplied Discovery Modes VDOs, the attacker can place a chosen value where the out-of-bounds read will occur and cause the kernel to treat that value as an SVID. The kernel may then register an alternate mode based on attacker-controlled data. Exploitation is local-adjacent/physical rather than network-based and depends on USB-C PD/TCPM code paths being active for the affected hardware and kernel build.

How to fix it

Apply a Linux kernel update that includes the TCPM fix validating that the SVID index is non-negative and strictly less than the discovered SVID count before accessing the SVID array in svdm_consume_modes(). If vendor fixed kernel versions are not listed for the relevant distribution or appliance, track the corresponding security advisory from the Linux distribution, device vendor, or appliance manufacturer and update to the first kernel build containing the upstream fix. Where immediate patching is not possible, reduce exposure by restricting physical access to USB-C ports, blocking untrusted USB-C docks/chargers/adapters/peripherals, disabling unused USB-C/Thunderbolt/alternate-mode functionality where operationally feasible, using USB device control policies, and favoring managed/known-good peripherals in sensitive areas.

How to confirm the fix worked

Confirm the running kernel package or image includes the upstream TCPM bounds-check fix in svdm_consume_modes(). On managed Linux systems, validate through the distribution's package changelog/security advisory, kernel build metadata, or source package diff rather than relying only on the kernel version string, because vendors often backport fixes. For source-based validation, confirm the TCPM code checks pmdata->svid_index against pmdata->nsvids before reading pmdata->svids[pmdata->svid_index]. For exposure validation, identify systems with USB-C ports using TCPM/Type-C kernel drivers loaded, review whether external USB-C peripherals are permitted, and test patched systems with known-good USB-C PD/alternate-mode devices to ensure normal port functionality remains intact.

Typical attack path

1. Prepare or obtain a USB-C/USB Power Delivery device capable of sending crafted SVDM responses.
2. Connect the malicious USB-C partner to a vulnerable Linux system with a TCPM-managed USB-C port.
3. Trigger USB-C alternate-mode discovery through normal Type-C/PD negotiation.
4. Send SVID and mode-discovery messages that cause the kernel's internal SVID index to exceed the valid SVID count.
5. Place an attacker-chosen SVID value in partner-controlled discovery-mode data adjacent to the SVID array.
6. Cause the vulnerable kernel to read that adjacent value as though it were a valid SVID.
7. Observe incorrect alternate-mode registration, Type-C subsystem state changes, kernel warnings, instability, or other downstream behavior.

How to detect it

This issue is difficult to detect after the fact because exploitation occurs during local USB-C/Power Delivery negotiation and may not leave a distinctive, CVE-specific artifact. Review kernel logs, system journals, endpoint telemetry, and device-management logs around times when USB-C devices, docks, chargers, adapters, or monitors were connected. Look for unexpected USB Type-C partner or alternate-mode registrations, unusual SVID values, repeated PD/SVDM negotiation failures, kernel warnings, UBSAN/KASAN out-of-bounds read reports, oops/panic events, or USB-C subsystem instability. Relevant log sources include dmesg, journalctl kernel logs, /var/log/kern.log, /var/log/messages, endpoint device-control logs, and physical access/peripheral inventory records. If kernel sanitizers are enabled, prioritize any out-of-bounds read reports referencing TCPM, Type-C, SVDM, svdm_consume_modes(), or typec_partner_register_altmode(). Also inspect /sys/class/typec/ for unexpected partner altmode entries after suspicious USB-C connections, recognizing that legitimate docks and displays commonly register alternate modes too.

• svdm_consume_modes
• typec_partner_register_altmode
• tcpm
• typec
• SVDM
• Structured VDM
• out-of-bounds read
• index out of bounds
• KASAN: slab-out-of-bounds
• UBSAN: array-index-out-of-bounds
• /sys/class/typec/
• /sys/class/typec/*-partner/
• /sys/class/typec/*-partner.*
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Inventory Linux endpoints, appliances, kiosks, lab systems, and embedded devices with accessible USB-C ports and TCPM/Type-C support.
• Patch affected Linux kernels through the relevant OS or vendor update channel as routine priority, escalating for shared, public, kiosk, high-sensitivity, or physically exposed systems.
• For systems that cannot be patched quickly, restrict physical USB-C access and prohibit untrusted USB-C docks, chargers, adapters, cables, and peripherals.
• Use endpoint device-control tooling or OS policy to limit newly connected USB/USB-C devices where supported.
• Review kernel and system logs on high-risk systems for Type-C/USB-PD anomalies, unexpected alternate-mode registrations, or crashes following USB-C device attachment.
• Coordinate with hardware, desktop engineering, and facilities teams so charging accessories and docks are sourced from approved suppliers only.
• Monitor Linux distribution and vendor advisories for fixed kernel builds, since exact fixed versions are vendor-specific and may be backported.