CVE-2026-89471

What it actually does

The Chrome OS USB-PD charger driver (cros_usbpd-charger) uses Embedded Controller-reported port counts as a loop bound when filling a fixed 8-entry kernel heap array of port pointers, without checking those counts against EC_USB_PD_MAX_PORTS. A malfunctioning, malicious, or compromised EC that reports consistent counts greater than 8 (up to 255) causes a slab out-of-bounds write of up to about 1976 bytes in charger_data allocated via devm_kzalloc. The result is kernel heap corruption that can crash the kernel or, depending on adjacent slab objects, enable arbitrary kernel memory overwrite, privilege escalation, or code execution in kernel context.

Why it matters to the business

Impact is concentrated on Chromebooks and other Linux systems that load the Chrome OS EC USB-PD charger driver: unexpected kernel panics, device instability, and in a worst case full OS compromise if the EC is untrustworthy. This is not a remote network wormable flaw (local/EC-facing), is not listed in CISA KEV, has no observed ransomware use, and has a low, flat EPSS (~0.0014). Organizations with Chromebook or Chrome OS fleets should still treat kernel heap corruption as a high-priority patch because a single compromised EC or local primitive can take down or take over the host. Absence of named threat-actor use and empty public fixed-version lists do not reduce the need to apply vendor kernel updates once they ship.

How an attack unfolds

An attacker who can influence Chrome OS Embedded Controller responses—via compromised or replaced EC firmware, malicious EC hardware, or another local primitive that spoofs EC command replies—returns matching USB-PD and charger port counts larger than eight. During driver probe, the kernel only sanity-checks that the two EC-reported u8 counts are consistent with each other, not that they fit in the eight-slot ports array. The probe loop then writes past the end of that array and corrupts neighboring slab memory. Heap layout and subsequent use of corrupted objects determine whether the host merely oopses or whether control flow or data structures in the kernel are hijacked. Exploitation requires local/EC-level influence, not unauthenticated network access, and public exploit maturity is currently none.

How to fix it

Apply the upstream Linux kernel change that rejects EC-reported port counts larger than EC_USB_PD_MAX_PORTS before they are used as loop bounds in cros_usbpd_charger_probe. Deploy the corresponding stable, distro, Chrome OS, or OEM kernel security update as soon as it is available; this advisory input does not list exact fixed package versions, so track vendor changelogs for the cros_usbpd-charger port-count bound. Until patched, treat EC firmware as a trusted computing base: keep EC firmware updated and integrity-checked. On systems that do not require Chrome EC USB-PD charger management, avoid loading the cros_usbpd-charger module (blacklist/disable) as a compensating control. Do not rely on the existing num_charger_ports vs num_usbpd_ports consistency check alone—it does not prevent this overflow.

How to confirm the fix worked

Confirm the running kernel or Chrome OS image includes the bounds check of EC-reported port counts against EC_USB_PD_MAX_PORTS in the cros_usbpd-charger probe path (source, distro changelog, or vendor security bulletin). After updating, verify the kernel/package version and that the cros_usbpd-charger module or built-in driver matches the patched tree. Review boot and driver-init logs for successful, bounded probe of the charger driver and absence of new slab/KASAN errors. Inventory hosts that load this driver (Chromebooks, Chrome OS, and Linux kernels built with the Chrome EC power-supply driver) to confirm coverage. Do not attempt to reproduce the overflow on production systems.

Typical attack path

1. Gain the ability to control or spoof Chrome OS Embedded Controller replies for USB-PD/charger port-count commands (compromised EC firmware, malicious EC, or a local EC-facing primitive).
2. Cause the cros_usbpd-charger driver to probe (boot, module load, or power-supply initialization).
3. Have the EC report num_usbpd_ports and num_charger_ports that pass the mutual-consistency check but exceed eight.
4. Trigger the unbounded loop that writes port pointers past the eight-entry ports array in kernel slab memory.
5. Leverage the resulting heap corruption to crash the kernel or overwrite adjacent kernel objects for privilege escalation.

How to detect it

This flaw is triggered at driver probe by untrusted EC port-count values, so look for evidence of kernel heap corruption or oops during charger/power-supply initialization rather than a distinctive network payload. Review kernel logs (dmesg, journalctl -k, serial/console, crash dumps, pstore, Chrome OS /var/log/messages and /var/log/net.log equivalents) around boot and module load for cros_usbpd-charger probe, slab-out-of-bounds or KASAN reports, and call traces naming cros_usbpd_charger_probe. Hunt for unexpected EC firmware versions, EC communication errors, and hosts that loaded cros_usbpd-charger before the patch. Memory-forensics on crashed systems may show corrupted slab objects adjacent to charger_data. There are no public in-the-wild campaigns or named threat actors tied to this CVE; absence of matching logs does not prove non-exploitation if the host panicked and logs were lost.

• cros_usbpd_charger_probe
• cros_usbpd-charger
• cros-usbpd-charger
• BUG: KASAN: slab-out-of-bounds
• slab-out-of-bounds in cros_usbpd
• Call Trace: cros_usbpd_charger
• EC_CMD_CHARGE_PORT_COUNT
• EC_CMD_USB_PD_PORTS
• num_charger_ports
• power_supply: cros_usbpd

What your security team should do

• Patch Linux/Chrome OS kernels that include cros_usbpd-charger as soon as vendor updates land; do not wait for KEV listing given CVSS 8.4 kernel heap corruption.
• Inventory devices and images that load cros_usbpd-charger or equivalent Chrome EC charger support and prioritize those fleets.
• Ensure Embedded Controller firmware is updated, measured, and treated as in-scope trusted hardware; investigate unexpected EC firmware or hardware changes.
• Where the driver is unused, blacklist or disable cros_usbpd-charger until kernels are patched.
• Alert on kernel oops, KASAN slab-out-of-bounds, and probe failures attributed to cros_usbpd-charger.
• Reassess after vendor fixed versions are published and confirm EPSS/KEV remains low; raise urgency if in-the-wild exploitation appears.