Look up another CVE · open CVE-2026-89471 in the interactive tracker
CVE-2026-89471
power: supply: cros_usbpd-charger: bound the EC-reported port count
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-89471 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
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 < charger->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 || 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.
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.19 | 5.10.270 | 0b5096f68041 |
| 4.19 | 5.15.221 | c46c9f447415 |
| 4.19 | 6.1.188 | a1905375dfc0 |
| 4.19 | 6.6.157 | 2746d502b12b |
| 4.19 | 6.12.109 | fd29d08ee487 |
| 4.19 | 6.18.50 | 78be8b7403ff |
| 4.19 | 7.2.4 | 3d1e01443b22 |
| 4.19 | 7.3 | 48355ce49359 |
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 overflow is in cros_usbpd_charger_probe(), reached when the Chrome OS EC MFD core instantiates the charger over LPC/eSPI/I2C/SPI and the driver reads EC_CMD_USB_PD_PORTS and EC_CMD_CHARGE_PORT_COUNT; USB-C PD is handled by the EC and there is no network or USB-packet path into this probe.
- AC:LAttack complexity, low
- A malicious or compromised EC fully controls the two u8 port counts; reporting equal values N>8 (for example both 255) passes the mutual sanity check and deterministically writes N pointers past the 8-entry ports[] array with no race or attacker-uncontrollable layout.
- PR:NPrivileges required, none
- The vulnerable probe runs automatically at boot when the CrOS EC advertises USB-PD; no Linux account, capability, or user-namespace privilege is required because the attacker is the EC supplying host-command responses, with no authentication on this path.
- UI:NUser interaction, none
- Driver enumeration and the overflowing registration loop execute during normal kernel boot or module load on Chromebooks, Framework laptops, and other CrOS-EC systems; no victim action such as plugging a peripheral or opening a device node is required.
- S:UScope, unchanged
- The slab out-of-bounds write corrupts kernel heap belonging to the same OS security authority as the charger driver; this is ordinary kernel memory corruption, not a VM escape or IOMMU/DMA boundary bypass.
- C:HConfidentiality impact, high
- The loop writes up to 247 kernel pointers (~1976 bytes) past the kmalloc'd charger_data into adjacent slab objects; that heap corruption can be leveraged for kernel-memory disclosure.
- I:HIntegrity impact, high
- This is a slab out-of-bounds write of port_data pointers that smashes charger_data.notifier (including notifier_call) and neighboring heap objects, which is exploitable for control-flow hijacking.
- A:HAvailability impact, high
- Overflowing the 8-entry ports[] array by hundreds of pointer writes corrupts SLUB metadata and adjacent objects and can oops or panic the kernel during probe.