CVE-2026-63961

What it actually does

This is an information-disclosure flaw in the Linux kernel USB Type-C DisplayPort Alternate Mode handling. A malformed or malicious USB-C/DisplayPort Alternate Mode device can provide an invalid object count for a Status Update VDO. If the kernel processes that count incorrectly, it may read uninitialized stack memory and transmit those bytes back through the USB-C/Type-C alternate-mode protocol. The issue does not directly provide code execution, but leaked kernel stack data can expose sensitive runtime information and may help an attacker develop or chain additional exploits.

Why it matters to the business

The primary business risk is exposure of data from Linux systems when users connect an untrusted or compromised USB-C device, dock, adapter, monitor, cable, or peripheral. The likelihood is relatively low because exploitation generally requires physical access or control of connected USB-C hardware, and the vulnerability is not listed in CISA KEV and has low EPSS at this time. However, organizations with shared workstations, kiosks, labs, developer systems, high-assurance endpoints, or environments where USB-C docks and displays are frequently used should treat it as a meaningful hardening priority because it can support follow-on exploitation.

How an attack unfolds

An attacker prepares or compromises a USB-C device capable of participating in USB Type-C DisplayPort Alternate Mode negotiation, such as a malicious dock, adapter, display, cable, or emulator. The attacker gets the target Linux system to connect to that device. During DisplayPort Alternate Mode status handling, the device sends a malformed Status Update VDO with an incorrect count. A vulnerable kernel fails to validate the count before reading the update object, causing it to read bytes from uninitialized kernel stack memory. Those bytes are then sent back through the protocol path where the malicious device can capture them. The attacker analyzes the leaked data for kernel pointers, memory layout details, or sensitive residual values that could aid a later attack.

How to fix it

Apply a Linux kernel update that includes the fix for USB Type-C DisplayPort Alternate Mode Status Update VDO count validation. If vendor-specific fixed versions are not available in the advisory data, use the latest security-supported kernel from the relevant distribution or appliance vendor and confirm the patch includes validation of the status update object count before reading the VDO. Where immediate patching is not possible, reduce exposure by restricting use of untrusted USB-C peripherals, docks, adapters, displays, and cables; enforcing physical port control policies; disabling USB-C DisplayPort Alternate Mode where operationally feasible; and using endpoint controls that block unauthorized USB/Thunderbolt-class devices.

How to confirm the fix worked

Confirm the running kernel version is at or above the vendor-provided fixed release for the affected distribution or product. Validate that the deployed kernel source or vendor changelog includes the USB Type-C DisplayPort Alternate Mode fix that validates the Status Update VDO count before reading it. Reboot systems after kernel installation and verify the active kernel with standard OS tooling, not just the installed package inventory. For exposure validation, identify Linux endpoints with USB-C ports and DisplayPort Alternate Mode support, especially systems that commonly use docks, monitors, or adapters. If feasible in a controlled lab, use a USB-C protocol test device or emulator to confirm malformed Status Update VDO messages are rejected without leaking data or causing anomalous kernel behavior.

Typical attack path

1. Obtain physical access to the target system or influence a user to connect a malicious USB-C dock, adapter, display, cable, or peripheral.
2. Have the malicious device negotiate USB Type-C DisplayPort Alternate Mode with the Linux host.
3. Send a malformed DisplayPort Alternate Mode Status Update VDO with an invalid object count.
4. Trigger the vulnerable kernel path that reads beyond initialized Status Update VDO data into stack memory.
5. Capture the leaked bytes transmitted back to the malicious device.
6. Analyze the leaked data for kernel memory layout details or other sensitive values useful for follow-on exploitation.

How to detect it

There is no reliable software-only indicator that confirms exploitation, because the attacker-controlled device may only receive leaked bytes over the USB-C alternate-mode protocol and the kernel may not log the malformed message. For retrospective review, examine endpoint telemetry, kernel logs, system journals, USB authorization logs, device-control events, EDR device events, and physical access records for unexpected USB-C, Type-C, DisplayPort Alternate Mode, dock, monitor, or adapter connections. Focus on time windows where sensitive systems were connected to unfamiliar peripherals or where repeated USB-C connect/disconnect events occurred. If hardware telemetry is available, review USB-C/PD controller, Thunderbolt, dock management, and peripheral inventory logs for unknown vendor/product identifiers or newly observed docking/display devices. Absence of logs should not be treated as proof that exploitation did not occur.

What your security team should do

• Prioritize kernel updates for Linux workstations, laptops, kiosks, developer machines, and shared systems that use USB-C docks, adapters, or DisplayPort Alternate Mode displays.
• Treat this as a physical-access or malicious-peripheral risk rather than an internet-exposed remote exploitation risk; align prioritization accordingly.
• Restrict untrusted USB-C peripherals and docks, especially in sensitive areas and on privileged engineering or administrative endpoints.
• Review device-control policies for USB-C, Thunderbolt, docking stations, external displays, and adapters; block unknown devices where business operations allow.
• For systems that cannot be patched quickly, consider disabling USB-C DisplayPort Alternate Mode or limiting access to USB-C ports through firmware, OS policy, endpoint management, or physical port blockers.
• Monitor kernel and endpoint logs for unusual USB-C, Type-C, DisplayPort Alternate Mode, or repeated connect/disconnect activity around sensitive systems.
• Educate users not to connect unknown USB-C docks, adapters, cables, displays, or chargers, particularly in travel, conference, lab, or shared-desk scenarios.