CVE-2026-63963

What it actually does

CVE-2026-63963 is an information disclosure flaw in the Linux kernel USB Type-C Port Controller Manager (TCPM) code path that handles USB Power Delivery Structured Vendor Defined Message (SVDM) Discover Identity acknowledgements. A connected USB Type-C/USB-PD device can supply a device-controlled Vendor Defined Object (VDO) count that is not properly validated before being passed to identity parsing helpers. If the count exceeds the expected bounds of static arrays, the kernel may read beyond the intended array contents and expose adjacent kernel memory data through the identity handling flow. The issue is not described as code execution or privilege escalation; the primary impact is unintended kernel memory disclosure to a malicious or malformed USB-C/USB-PD peer.

Why it matters to the business

Systems that accept untrusted USB-C peripherals could leak sensitive kernel memory when interacting with a malicious or specially crafted USB-C/USB-PD device. The practical business risk is highest for laptops, workstations, kiosks, labs, shared devices, and operational systems where physical peripheral access is plausible. Remote exploitation is not expected from the provided details, EPSS is low at 0.002, there is no known CISA KEV listing, no ransomware association, and no public exploit maturity reported, so this should be treated as a kernel hardening and physical-access exposure rather than an internet-scale emergency. Organizations with large Linux endpoint or embedded fleets should still prioritize routine kernel updates because USB-C controller code is broadly deployed and memory disclosure flaws can assist later exploitation chains.

How an attack unfolds

An attacker needs the ability to connect or emulate a USB Type-C/USB Power Delivery device to a vulnerable Linux system. During USB-PD negotiation, the attacker-controlled device sends a crafted Discover Identity ACK containing an invalid or excessive VDO count. The vulnerable TCPM handler trusts that count when processing identity data and calls the relevant SVDM identity consumption helper. Because the count is not sufficiently bounded, kernel code can index outside the intended static VDO arrays and include unintended adjacent memory in the data it processes or returns. The attacker then observes the protocol response or resulting exposed identity data to recover leaked kernel memory. In a realistic campaign, this would most likely be used as a local physical-access technique, a malicious peripheral attack, or a supporting primitive to bypass kernel memory-layout protections rather than as a standalone remote compromise.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the TCPM Discover Identity ACK VDO count validation issue. Where distributions provide backported security kernels, use the vendor-fixed kernel package rather than relying only on upstream version numbers. If immediate patching is not possible, reduce exposure by restricting physical access to affected systems, disabling or controlling use of USB-C/USB-PD ports where operationally feasible, using endpoint device-control policies to block untrusted USB peripherals, and avoiding connection of unknown chargers, docks, hubs, cables, or development boards. For embedded products, appliances, and custom kernels, backport the patch that validates VDO counts before calls to svdm_consume_identity() and svdm_consume_identity_sop_prime(). Reboot affected systems after kernel replacement so the fixed kernel is actually running.

How to confirm the fix worked

Confirm the running kernel includes the vendor security update or the upstream patch that adds VDO count validation in the USB Type-C TCPM Discover Identity ACK handling paths. Validate both installed and running kernel versions because Linux kernel fixes usually require a reboot. Review distribution advisories for this CVE and verify the deployed package version is listed as fixed. On custom kernels, inspect the relevant TCPM source to ensure Discover Identity ACK handlers bound-check the VDO count before invoking svdm_consume_identity() or svdm_consume_identity_sop_prime(). For exposure validation, inventory Linux systems with enabled USB-C/USB Power Delivery support and prioritize portable, publicly accessible, shared, kiosk, lab, and embedded devices. Functional testing can include connecting normal USB-C/USB-PD peripherals and confirming no regressions in charging, alternate mode, docking, and identity discovery behavior after patching.

Typical attack path

1. Obtain physical access to a vulnerable Linux system with an enabled USB-C/USB Power Delivery port, or place a malicious USB-C/USB-PD peripheral where it will be connected.
2. Emulate or use a crafted USB-C/USB-PD device capable of sending malformed Structured Vendor Defined Messages.
3. Initiate USB-PD negotiation with the target host.
4. Send a Discover Identity ACK with a manipulated VDO count that exceeds the expected valid range.
5. Trigger the vulnerable TCPM Discover Identity ACK handler to process the attacker-controlled count.
6. Cause an out-of-bounds read from static identity-related arrays in kernel memory.
7. Capture any leaked identity response data or side effects exposed through the USB-PD interaction.
8. Optionally use the disclosed kernel memory as reconnaissance for a follow-on local exploitation chain.

How to detect it

Detection is challenging because the vulnerability is triggered through low-level USB-C/USB Power Delivery message handling and may not produce a clear application-level log entry. Focus retrospective review on systems where untrusted physical peripheral access is plausible. Collect kernel logs, system journal data, USB subsystem logs, endpoint device-control telemetry, EDR device insertion events, and physical access records around suspicious USB-C connection times. Look for repeated USB-C attach/detach cycles, unusual or unknown USB-PD partners, Type-C alternate mode negotiation failures, Discover Identity or SVDM-related errors, kernel warnings from TCPM/typec code, and anomalous peripherals such as unexpected docks, chargers, hubs, development boards, or USB-PD emulators. If kernel crash dumps, warnings, or KASAN reports are available, search for out-of-bounds reads in TCPM, SVDM, or identity parsing functions. Because the provided intelligence does not identify public exploit tools, named threat actors, or stable payload artifacts, absence of these indicators does not prove non-exploitation. For suspected cases, preserve the suspect peripheral, acquire kernel logs, collect EDR USB insertion history, and compare device connection timelines with user presence and physical access records.

• svdm_consume_identity
• svdm_consume_identity_sop_prime
• tcpm
• typec
• USB Power Delivery
• Discover Identity
• SVDM
• Structured Vendor Defined Message
• VDO
• out-of-bounds read
• kernel: tcpm
• kernel: typec
• usb: typec: tcpm
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• UBSAN: array-index-out-of-bounds

What your security team should do

• Inventory Linux endpoints, servers, appliances, and embedded systems with USB-C/USB Power Delivery capabilities, especially devices exposed to public or shared physical access.
• Patch affected Linux kernels through the operating-system vendor’s security update channel and reboot to activate the fixed kernel.
• Prioritize laptops, kiosks, lab systems, developer workstations, shared work areas, and embedded/OT-adjacent Linux devices where untrusted USB-C peripherals may be connected.
• For custom or vendor-maintained kernels, request or backport the upstream TCPM VDO count validation fix and include it in the next firmware or kernel maintenance release.
• Until patched, enforce physical security and user guidance against unknown USB-C chargers, docks, hubs, cables, adapters, and development boards.
• Use endpoint control or BIOS/UEFI/firmware controls where available to restrict untrusted USB and USB-C functionality on high-risk systems.
• Monitor kernel logs for USB Type-C/USB-PD negotiation anomalies, repeated connect/disconnect events, or malformed identity discovery behavior on sensitive systems.
• Treat confirmed exploitation as a local physical-access incident and investigate for malicious peripherals and follow-on activity rather than assuming remote network compromise.