Look up another CVE · open CVE-2026-89470 in the interactive tracker
CVE-2026-89470
power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem drivers/power. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-89470 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Currently the cros_usbpd-charger driver probe iterates based on raw charger port count returned by the embedded controller. The only check is against the number of USB PD ports which the embedded controller also defines. A malicious embedded controller could return an inaccurate port count (up to 255) resulting in an out of bounds write and subsequent memory corruption. Update helper functions in cros_usbpd-charger to limit port counts to EC_USB_PD_MAX_PORTS.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/power/supply/cros_usbpd-charger.c
- What this is
- CHROMEOS EC SUBDRIVERSMAINTAINERS section matched on drivers/power/supply/cros_usbpd-charger.c · chrome-platform@lists.linux.dev · Maintained
- Kernel module
- cros_usbpd_charger
Check it on the machine
grep -wE 'CONFIG_CHARGER_CROS_USBPD|CONFIG_POWER_SUPPLY' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w cros_usbpd_chargerPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, i386/686, i386/686-pae, i386/rt/686-pae, ppc64el/powerpc64le
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_CHARGER_CROS_USBPD, CONFIG_POWER_SUPPLY
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 8.4 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.14%, higher than 3.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/power
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.20 | 5.10.270 | e951b65ef169 |
| 4.20 | 5.15.221 | 3ce9218639ff |
| 4.20 | 6.1.188 | dce1750ddbd3 |
| 4.20 | 6.6.157 | 3262977a05b2 |
| 4.20 | 6.12.109 | fd5f289cca04 |
| 4.20 | 6.18.50 | 4b1f2be1e1b7 |
| 4.20 | 7.2.4 | 304a29ac55ba |
| 4.20 | 7.3 | 657cd3a42e93 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The OOB write is in cros_usbpd_charger_probe() on the Chrome OS EC platform path (LPC/eSPI/I2C/SPI/UART/ISHTP → cros_ec_cmd_xfer_status → MFD cell cros-usbpd-charger). Port counts come from the onboard EC, not from network packets or a USB-C partner, so the highest defensible vector is local.
- AC:LAttack complexity, low
- A malicious or compromised EC fully controls both u8 replies (EC_CMD_USB_PD_PORTS and EC_CMD_CHARGE_PORT_COUNT). Setting them equal and greater than 8 (for example both 255) passes the relative sanity check and makes the probe loop overflow ports[EC_USB_PD_MAX_PORTS] deterministically, with no race or layout lottery.
- PR:NPrivileges required, none
- ec_device_probe() auto-adds the charger cell when the EC advertises USB-PD and probe then trusts EC replies with no Linux capability or credential check. Supply-chain or already-compromised EC firmware needs no host account, matching other firmware-at-probe kernel CNA scores.
- UI:NUser interaction, none
- The charger driver probes automatically during Chrome OS EC MFD bring-up at boot or module load. No victim action such as plugging a cable, mounting a filesystem, or opening a device node is required.
- S:UScope, unchanged
- Impact is kernel slab corruption and possible code execution on the same host that runs the charger driver. This is not a VM escape, IOMMU/DMA boundary bypass, or other cross-authority breakout.
- C:HConfidentiality impact, high
- The probe writes up to 247 pointers past the 8-entry ports[] array in the kmalloc'd charger_data (about 1976 bytes on 64-bit), corrupting adjacent slab objects. That heap overflow can be turned into an arbitrary-read primitive, not a small bounded leak.
- I:HIntegrity impact, high
- The overflow stores attacker-timed port_data pointers past ports[] (and can also overflow each port's name[] via sprintf for i>=10), enabling adjacent-object corruption, control-flow hijack, and arbitrary write.
- A:HAvailability impact, high
- Smashing charger_data's trailing notifier_block and neighboring slab objects during probe can oops or panic the kernel on Chromebooks and other Chrome OS EC systems, a full availability loss.