CVE-2026-89470

What it actually does

The Linux kernel cros_usbpd-charger driver iterated on the raw USB PD charger port count returned by the Chrome OS embedded controller (EC) and only compared it against the EC-defined port total, without capping it at EC_USB_PD_MAX_PORTS. A malicious or compromised EC can return a count up to 255, causing probe/helper paths to walk past allocated port arrays and perform an out-of-bounds write in kernel memory. The result is kernel-space memory corruption (buffer overflow) that can overwrite adjacent structures, crash the kernel, or enable arbitrary kernel-context code execution and local privilege escalation.

Why it matters to the business

Hosts that use Cros EC USB PD charging—primarily Chromebooks, Chromium OS derivatives, and Linux systems with this driver—can suffer full OS compromise, data loss, or unplanned kernel panics if the EC is untrusted. The attack is local to the host–EC interface (CVSS 8.4, AV:L, no privileges or user interaction), not a remote network worm. About 31 days after publication there is no KEV listing, no ransomware use, exploit maturity is none, and EPSS remains ~0.0014 with no 30-day rise, so treat this as a high-severity but niche kernel defect: patch Chrome OS / Cros-EC fleets on the normal urgent-kernel cadence rather than as an internet-facing emergency.

How an attack unfolds

The attacker first needs influence over the embedded controller that the cros_usbpd-charger driver queries—compromised or unsigned EC firmware, physical access to the EC channel, or a replaced controller. On boot, resume, or module probe the kernel asks the EC for the charger port count. The EC returns an inflated value above EC_USB_PD_MAX_PORTS (up to 255). Unbounded helper loops then write past the intended port structures, corrupting kernel memory. From that write primitive the attacker can attempt to redirect kernel control flow, disable mitigations, implant persistence, or force a denial of service. No remote unauthenticated network path is described, and no named APT or ransomware campaign is associated with this CVE.

How to fix it

Install a Linux/Chrome OS kernel that includes the fix 'power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS', which caps all cros_usbpd-charger port-count handling at EC_USB_PD_MAX_PORTS. Follow your distribution or Chrome OS security tracker for the patched kernel package; this advisory did not list exact version numbers. Until patched, treat EC firmware as part of the TCB (signed, measured, vendor-supplied images only), restrict physical service access to the EC, and blacklist or unload cros_usbpd-charger on systems that do not use Cros USB PD charging.

How to confirm the fix worked

Confirm the running kernel changelog or cros_usbpd-charger source bounds port counts with EC_USB_PD_MAX_PORTS in the charger probe/helpers. Match the installed kernel/Chrome OS package to the vendor advisory. On live hosts, review dmesg/journal for charger probe lines and verify reported port counts never exceed the documented maximum. Systems that never load cros_usbpd-charger or lack a Cros EC are not exposed. After patching, regression-test charging/USB PD behavior and confirm no oopses during probe.

Typical attack path

1. Gain local access to a device that loads cros_usbpd-charger, or compromise/replace Cros EC firmware so the EC can return attacker-chosen port counts
2. Cause the charger driver to probe (cold boot, resume, or module load)
3. Have the EC report a USB PD / charger port count greater than EC_USB_PD_MAX_PORTS (up to 255)
4. Trigger unbounded iteration in cros_usbpd-charger helpers so kernel memory is written out of bounds
5. Abuse the resulting kernel memory corruption for local privilege escalation, persistence, or a kernel panic

How to detect it

Successful or attempted abuse shows up as kernel memory corruption during charger driver probe, not as a network signature. Search persistent kernel logs (dmesg, journalctl -k, pstore/ramoops, vmcore/kdump) around boot, resume, and module load for oops/panic stacks in cros_usbpd-charger, cros_usbpd_charger_probe, or related power_supply helpers, and for charger port counts that look implausibly high. Compare EC firmware versions and measurements to known-good images and note unexpected EC replacements or unsigned updates. There are no public exploits, named threat actors, or ransomware campaigns tied to this issue, so treat matching oopses plus anomalous EC firmware as the primary historical-compromise signal.

• cros_usbpd-charger
• cros_usbpd_charger_probe
• cros-usbpd-charger
• Oops:.*cros_usbpd
• BUG:.*cros_usbpd
• Unable to handle kernel.*cros_usbpd
• power_supply: cros_usbpd

What your security team should do

• Inventory Chrome OS, Chromium OS, and Linux hosts that load cros_usbpd-charger or communicate with a Cros USB PD EC
• Patch those kernels as soon as vendor packages containing the EC_USB_PD_MAX_PORTS cap are available
• Until patched, enforce signed/measured EC firmware and limit physical access to devices and debug interfaces
• Do not treat this as a mass internet-facing emergency: EPSS is ~0.0014 and stable, it is not in KEV, and there is no known exploit or ransomware use
• Monitor kernel oops/panic telemetry for cros_usbpd-charger probe paths as an early signal of buggy or malicious ECs