CVE-2026-93190: platform/chrome: cros_ec_typec: Reject out-of-bounds PD cap count
In the Linux kernel, the following vulnerability has been resolved:
platform/chrome: crosectypec: Reject out-of-bounds PD cap count
crostypecregisterpartnerpdos() copies the partner PDOs from the EC TYPECSTATUS response into the fixed capsdesc.pdo[PDOMAXOBJECTS] array.
memcpy(capsdesc.pdo, resp->sourcecappdos, sizeof(u32) resp->sourcecapcount); ... memcpy(capsdesc.pdo, resp->sinkcappdos, sizeof(u32) resp->sinkcapcount);
PDOMAXOBJECTS is 7. sourcecapcount and sinkcapcount 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 crostypecregisterpartnerpdos() next to the memcpy. Skip the PDO registration if either count is above PDOMAXOBJECTS. The rest of crostypechandlestatus() still runs so events are handled and cleared.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In the Linux kernel code path for ChromeOS EC Type-C handling, validate resp->sink_cap_count and resp->source_cap_count before copying into caps_desc.pdo[PDO_MAX_OBJECTS]: skip PDO registration when either count is above PDO_MAX_OBJECTS (set PDO_MAX_OBJECTS = 7) to prevent memcpy writing past caps_desc.pdo array on the stack.
Linux kernel cros_typec_register_partner_pdos() / cros_typec_handle_status() PD cap count validation = Reject counts above 7 (PDO_MAX_OBJECTS)
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems using the Linux kernel ChromeOS EC Type-C driver are exposed when the embedded controller supplies a TYPEC_STATUS response with a source or sink PDO capability count greater than 7. Compliant ChromeOS EC firmware caps these counts today, so normal compliant configurations do not trigger the condition.
What must an attacker control to trigger the overflow?
An attacker would need to cause the EC-provided source_cap_count or sink_cap_count field to exceed PDO_MAX_OBJECTS, which is 7. The vulnerable code trusts these u8 count fields and uses them as the length for stack memcpy operations.
What can be done if the kernel update cannot be applied immediately?
The provided data identifies compliant ChromeOS EC firmware as capping the counts and therefore avoiding the condition. No other mitigation is specified; the kernel-side fix validates both counts and skips PDO registration when either exceeds 7.
How can administrators determine whether the vulnerable condition is occurring?
The condition requires an EC TYPEC_STATUS response reporting a source or sink capability count above 7. The vulnerable code only checks that the two counts are not both zero, so observing either count greater than 7 indicates the out-of-bounds copy path can be reached.