Cloudanix VulnDB

CVE-2026-93190

High · 8.4

CVSS

8.4

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A missing check when reading power data from USB-C hardware allows the system to copy too much information and potentially let attackers take control of the computer.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Buffer Overflow
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Out-of-bounds write via unchecked memcpy of source_cap_count or sink_cap_count (u8 values up to 255) into the fixed-size caps_desc.pdo[PDO_MAX_OBJECTS] stack array (size 7), also reading past EC source arrays.

Why it matters to the business

Kernel-level compromise on affected Linux/ChromeOS systems can lead to local privilege escalation, arbitrary code execution, or system crashes, impacting device security and availability.

How an attack unfolds

An attacker with the ability to influence or spoof TYPEC_STATUS responses from the Chrome EC (such as through compromised firmware) supplies counts exceeding PDO_MAX_OBJECTS, triggering the overflowing memcpy during partner PDO registration.

How to fix it

Update the Linux kernel to a version containing the patch that validates source_cap_count and sink_cap_count against PDO_MAX_OBJECTS before any memcpy in cros_typec_register_partner_pdos; skip PDO registration for invalid counts.

How to confirm the fix worked

Inspect kernel source for the added bounds check next to the memcpy calls; confirm no registration occurs for counts > 7; test with simulated oversized EC responses.

Typical attack path

  1. Obtain control over Chrome EC firmware or hardware responses
  2. Craft TYPEC_STATUS message with source_cap_count or sink_cap_count > 7
  3. Trigger cros_typec_handle_status and cros_typec_register_partner_pdos
  4. Perform out-of-bounds memcpy to corrupt kernel stack
  5. Achieve code execution or cause denial of service

How to detect it

Review kernel logs and crash reports for oops/panics or stack corruption involving cros_ec_typec or cros_typec_register_partner_pdos; correlate with unusual TYPEC_STATUS events from the EC.

What your security team should do

  • Apply the validating kernel patch immediately on all Chrome EC Type-C systems
  • Monitor EC firmware updates for compliant count capping
  • Enable kernel hardening features such as stack protection
  • Audit for any custom EC integrations that bypass the fix

The record

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.

Affected packages

Ecosystem Package Introduced Fixed