ZeroHour

CVE-2026-89471

mass

Slab out-of-bounds write in Linux kernel cros_usbpd-charger via EC port count

CVSS 3.1
8.4 high
EPSS
Published
()
Modified
AI analysis

The Linux kernel's cros_usbpd-charger driver (power: supply) trusts a u8 charger port count reported by the Embedded Controller and uses it as the loop bound when filling a fixed 8-entry ports[] array inside the devm_kzalloc()'d charger_data structure. Because the driver never validates either EC-reported count (num_usbpd_ports or num_charger_ports) against EC_USB_PD_MAX_PORTS, an EC that reports N > 8 matching values (e.g., both 255) passes the existing cross-check and causes up to 247 pointers (~1976 bytes) to be written past the array — a slab out-of-bounds write during driver probe. An attacker gains kernel memory corruption on the affected machine (potential privilege escalation, code execution, or crash), but the malicious values must originate from the EC itself, so the precondition is a malfunctioning, buggy, or already-compromised EC firmware. Affected systems are those running kernel releases with the ChromeOS-EC-based cros_usbpd-charger driver — primarily Chromebooks/ChromeOS devices and other ChromeOS-EC hardware — prior to the upstream fix that rejects counts larger than the array can hold. No public PoC exists, the CVE is not in CISA's KEV, and no exploitation in the wild has been reported; the flaw was fixed as routine kernel hardening.

What to do: Update to a kernel release containing the upstream fix that rejects EC-reported port counts above EC_USB_PD_MAX_PORTS (8); on ChromeOS, confirm devices have applied the automatic update carrying the patched kernel. If you build custom kernels for ChromeOS-EC hardware, backport the patch or disable CONFIG_CHARGER_CROS_USBPD. Treat EC firmware integrity as a trusted boundary: keep EC firmware current and investigate unexpected or mismatched EC firmware versions, since a compromised or buggy EC is the prerequisite for triggering this bug.

Affected
Linux kernel (kernel.org) Linux kernel, drivers/power/supply/cros_usbpd-charger
Google ChromeOS / ChromeOS-EC based systems (Chromebooks, Chromeboxes) and other hardware running the ChromeOS EC with this dri
Estimated exposure
masstens of millions of devices (order of magnitude ~10^7) ship with this driver compiled in, though practical exposure is far smaller because triggering the bug… — The driver is enabled by default on ChromeOS-EC platforms, whose installed base (Google-reported ChromeOS/Chromebook users in education, enterprise, and consumer markets) is estimated in the tens of millions; this is an estimate based on…

Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.

Description

In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd-charger: bound the EC-reported port count cros_usbpd_charger_probe() reads two port counts from the EC and uses one of them, num_charger_ports, as the loop bound when populating a fixed-size array: struct port_data *ports[EC_USB_PD_MAX_PORTS]; /* 8 entries */ ... for (i = 0; i num_charger_ports; i++) charger->ports[charger->num_registered_psy++] = port; Both num_usbpd_ports (from EC_CMD_USB_PD_PORTS) and num_charger_ports (from EC_CMD_CHARGE_PORT_COUNT) are u8 values reported by the EC. The only validation is a sanity check that compares the two EC-reported values against each other: if (num_charger_ports num_usbpd_ports + 1) return -EPROTO; It never checks either count against EC_USB_PD_MAX_PORTS, the size of the ports[] array. A malfunctioning, malicious or compromised EC that reports num_usbpd_ports == num_charger_ports == N for any N > 8 (for example both 255) passes this check, and the loop then writes N pointers into the 8-entry ports[] array embedded in the devm_kzalloc()'d charger_data, overflowing it by up to 255 - 8 = 247 entries (~1976 bytes): a slab out-of-bounds write. Reject a port count larger than the ports[] array can hold.

Vector
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

In the news

No ingested article mentions this CVE yet.