CVE-2026-90025 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: displayport: Fix OOB altmode array index
The UCSI displayport driver indexes the connector's port altmode array with the GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not equal to 0xff, the kernel may crash with an array index OOB error.
Update the UCSI displayport driver to verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in the Linux kernel's USB Type-C Connector System Software Interface (UCSI) DisplayPort driver represents a critical out-of-bounds memory access issue rooted in insufficient input validation of hardware-reported data. The UCSI specification defines a standardized interface for communicating with Port Partner Management Modules, which manage alternate modes such as DisplayPort over USB Type-C connectors. Within this framework, the kernel driver interacts with the hardware to determine current Alternate Mode capabilities by issuing GET_CURRENT_CAM commands and processing the responses returned by the physical port partner or controller firmware. The specific flaw occurs when the driver attempts to index into a static array named altmode, which is sized according to UCSI_MAX_ALTMODES, using an identifier derived directly from this hardware response without rigorous bounds checking beyond a simple non-zero check against 0xff.
From a technical perspective, the root cause lies in the assumption that the value returned by the GET_CURRENT_CAM operation will always fall within the expected range of valid alternate mode identifiers supported by the driver implementation. While the code correctly filters out the specific sentinel value 0xff to prevent accessing invalid or null entries, it fails to verify that the index is strictly less than UCSI_MAX_ALTMODES. If a compromised device, a malfunctioning peripheral, or maliciously crafted hardware firmware returns an identifier greater than or equal to UCSI_MAX_ALTMODES but not equal to 0xff, the driver proceeds to use this value as an array subscript. This results in reading from or writing to memory locations outside the allocated bounds of the altmode array, leading to undefined behavior that typically manifests as a kernel panic due to page faults or general protection faults within the kernel space.
The operational impact of this vulnerability is severe, primarily affecting system stability and availability rather than confidentiality or integrity directly through remote exploitation vectors typical in user-space applications. An attacker with physical access to the device could exploit this by connecting a malicious USB Type-C peripheral that responds to GET_CURRENT_CAM queries with an out-of-bounds index value. Upon connection, the kernel would attempt to dereference the invalid pointer, causing an immediate crash of the operating system. This constitutes a denial of service condition where the affected machine becomes unresponsive and requires a hard reset or reboot to restore functionality. In environments requiring high availability, such as servers or critical infrastructure control systems, this physical-layer vulnerability poses a significant risk to operational continuity.
This flaw aligns with CWE-125, which describes Out-of-bounds Read vulnerabilities, where software reads data past the end of a buffer due to insufficient boundary checks on array indices. Furthermore, from an adversarial simulation perspective using the MITRE ATT&CK framework, this vulnerability facilitates Initial Access and Execution phases through physical interaction, specifically leveraging techniques associated with hardware-based attacks or peripheral device exploitation. The lack of strict validation against maximum allowable values allows for predictable memory corruption patterns that can be reliably triggered by a connected device acting as an attack vector.
Mitigation strategies must focus on enforcing strict bounds checking at the point of data ingestion from external sources. Developers should update the UCSI displayport driver to explicitly verify that the current alternate mode identifier returned by the hardware is strictly less than UCSI_MAX_ALTMODES before using it as an index into the altmode array. This defensive programming practice ensures that any anomalous or malicious values received from the port partner are rejected safely, preventing memory corruption. Additionally, implementing runtime assertions during development and thorough fuzz testing of USB Type-C interfaces can help identify similar validation gaps in other drivers within the kernel codebase to prevent recurrence of such out-of-bounds access issues.