CVE-2026-93190
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
platform/chrome: cros_ec_typec: Reject out-of-bounds PD cap count
cros_typec_register_partner_pdos() copies the partner PDOs from the EC TYPEC_STATUS response into the fixed caps_desc.pdo[PDO_MAX_OBJECTS] array.
memcpy(caps_desc.pdo, resp->source_cap_pdos, sizeof(u32) * resp->source_cap_count); ... memcpy(caps_desc.pdo, resp->sink_cap_pdos, sizeof(u32) * resp->sink_cap_count);
PDO_MAX_OBJECTS is 7. source_cap_count and sink_cap_count are u8 fields from the EC. The only check is that they are not both zero. If either is larger than 7, the memcpy writes past the end of the array on the stack. A count of 255 overflows it by about 1 KB. The EC source arrays are only seven entries wide. A larger count reads past them too.
The ChromeOS EC firmware caps these counts today, so a compliant setup does not hit this. The kernel should still validate these values rather than trust them.
Validate the counts in cros_typec_register_partner_pdos() next to the memcpy. Skip the PDO registration if either count is above PDO_MAX_OBJECTS. The rest of cros_typec_handle_status() still runs so events are handled and cleared.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified within the Linux kernel's ChromeOS EC Type-C driver represents a classic stack-based buffer overflow resulting from insufficient input validation on data received from external hardware interfaces. Specifically, in the function cros_typec_register_partner_pdos(), the code performs memory copy operations to transfer Power Delivery Object descriptors from an embedded controller response into a fixed-size local array named caps_desc.pdo. This array is statically defined with a maximum capacity of seven 32-bit words, corresponding to PDO_MAX_OBJECTS. The source data for these copies originates from resp->source_cap_pdos and resp->sink_cap_pdos, which are fields within the TYPEC_STATUS response structure provided by the ChromeOS Embedded Controller via its communication interface.
The core technical flaw lies in the logic governing the length of these memory copy operations. While the code verifies that neither source nor sink capability counts are zero, it fails to enforce an upper bound check against PDO_MAX_OBJECTS before invoking memcpy. The variables resp->source_cap_count and resp->sink_cap_count are defined as unsigned 8-bit integers, allowing values up to two hundred fifty-five. Consequently, if a malicious or malfunctioning device reports a count greater than seven, the memcpy operation will write data beyond the allocated stack space of the pdo array. This out-of-bounds write can corrupt adjacent stack memory, potentially overwriting return addresses, saved frame pointers, or other critical control flow data structures. In severe scenarios, this corruption could lead to arbitrary code execution if an attacker can precisely craft the input values and exploit the resulting memory state changes during function return.
Furthermore, the vulnerability extends beyond simple buffer overflow risks due to the nature of the source arrays themselves. The EC's internal source arrays are also limited to seven entries. If a device reports a count exceeding this limit, the kernel not only writes past its own stack array but also reads past the end of the EC-provided data buffers during the copy operation. This constitutes an out-of-bounds read vulnerability, which can lead to information disclosure by leaking sensitive memory contents from either the kernel stack or adjacent hardware buffer regions into user-accessible structures or logs depending on subsequent processing paths.
From a threat modeling perspective, this flaw aligns with CWE-120 Buffer Copy without Checking Size of Input and CWE-787 Out-of-bounds Write. It also relates to CWE-125 Out-of-bounds Read due to the excessive read operations from EC buffers. In terms of attack vectors, this vulnerability falls under ATT&CK technique T1608 Link Exploitation, as it involves compromising a trusted connection between components (host and embedded controller) by exploiting trust in input data integrity. Although current ChromeOS firmware implementations typically cap these counts to prevent exploitation, the principle of defense-in-depth dictates that kernel drivers must never blindly trust external hardware inputs without rigorous validation.
The operational impact of this vulnerability is significant for systems relying on USB Type-C connections with Power Delivery capabilities. An attacker with physical access or control over a connected peripheral could potentially crash the system through stack corruption leading to a kernel panic, thereby causing denial of service. More critically, sophisticated exploitation could allow privilege escalation from user space to ring zero if the corrupted stack data facilitates code execution in kernel context. This undermines the security boundary between hardware peripherals and the operating system core.
To mitigate this vulnerability, it is imperative that developers implement strict bounds checking immediately prior to any memory copy operations involving external inputs. In this specific case, the fix involves validating that both source_cap_count and sink_cap_count are less than or equal to PDO_MAX_OBJECTS before proceeding with the memcpy calls. If either count exceeds the maximum allowed value, the registration of Power Delivery objects should be skipped for those categories while allowing other status handling routines to continue executing normally. This ensures system stability is maintained even when invalid data is received, preventing stack corruption and preserving the integrity of kernel memory structures against malformed hardware responses.