Look up another CVE · open CVE-2026-64420 in the interactive tracker

CVE-2026-64420

mfd: cros_ec: Delay dev_set_drvdata() until probe success

7.0 EPSS 0.1% AV:L

Published 2026-07-25 (3 months ago) by the Linux kernel CNA. Subsystem drivers/mfd. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-64420 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-4720-1 · 2026-08-05 · text	6.1.180-1	Update the kernel and reboot. DLA-4720-1 shipped the fix on 2026-08-05, in 6.1.180-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixie	fixed	6.12.96-1	Update the kernel and reboot. Fixed in 6.12.96-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	7.1.4-1	Update the kernel and reboot. Fixed in 7.1.4-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.1.4-1	Update the kernel and reboot. Fixed in 7.1.4-1. A running kernel keeps the old code until the machine restarts.
Debian 12bookworm · linux-6.12	fixedDLA-4724-1 · 2026-08-07 · text	6.12.100-1~deb12u1	Update the kernel and reboot. DLA-4724-1 shipped the fix on 2026-08-07, in 6.12.100-1~deb12u1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

If ec_device_probe() fails, cros_ec_class_release releases memory for the cros_ec_dev structure. However, because the drvdata was already set, sub-drivers like cros_ec_typec can still retrieve the stale pointer via the platform device. This leads to a use-after-free when cros_ec_typec attempts to access &typec->ec->ec->dev on a device that has already been released. Move dev_set_drvdata() to ensure that the pointer is only made available once all initialization steps have succeeded. sysfs: cannot create duplicate filename '/class/chromeos/cros_ec' Call trace: sysfs_do_create_link_sd+0x94/0xdc sysfs_create_link+0x30/0x44 device_add_class_symlinks+0x90/0x13c device_add+0xf0/0x50c ec_device_probe+0x150/0x4f0 platform_probe+0xa0/0xe0 ... BUG: KASAN: invalid-access in __memcpy+0x44/0x230 Write at addr f5ffff809e2d33ac by task kworker/u32:5/125 Pointer tag: [f5], memory tag: [fe] Tainted : [W]=WARN, [O]=OOT_MODULE Hardware name: Google Navi unprovisioned 0x7FFFFFFF/sku0 board/sku3 Workqueue: events_unbound deferred_probe_work_func Call trace: __memcpy+0x44/0x230 cros_ec_check_features+0x60/0xcc [cros_ec_proto] cros_typec_probe+0xe8/0x6e0 [cros_ec_typec] platform_probe+0xa0/0xe0

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/mfd/cros_ec_dev.c

What this is: MULTIFUNCTION DEVICES (MFD)MAINTAINERS section matched on drivers/mfd/ · mfd@lists.linux.dev · Maintained
Kernel module: cros_ec_dev

Check it on the machine

grep -w CONFIG_MFD_CROS_EC_DEV /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_ec_dev

Prints 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/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, 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 switch: CONFIG_MFD_CROS_EC_DEV

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

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-07-25 (3 months ago)source
CVSS: 7.0 high
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: local (AV:L)source
EPSS: 0.12%, higher than 1.6% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: drivers/mfd

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
4.12	5.10.261	24522713034d
4.12	5.15.212	f7e81dc181d9
4.12	6.1.178	257203d83204
4.12	6.6.145	729ae27dc250
4.12	6.12.96	ed2941e5db01
4.12	6.18.39	b5f41d5bf08e
4.12	7.1.4	fc030c5b116f
4.12	7.2	8b2c1d41bc36

Debian advisories

Advisory	Date	Shipped to	Debian
DLA-4724-1	2026-08-07	bookworm 6.12.100-1~deb12u1	tracker
DLA-4723-1	2026-08-07	bullseye 6.1.180-1~deb11u1	tracker
DLA-4720-1	2026-08-05	bookworm 6.1.180-1	tracker
DLA-4717-1	2026-08-05	bullseye 5.10.262-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 UAF occurs in local platform-device probe work for an internally connected ChromeOS EC and its Type-C child, with no network or USB-peer entry point. Exploitation would require local heap shaping or probe-timing influence.
AC:HAttack complexity, high: Exploitation requires EC probe failure, such as a duplicate class name, while the Type-C probe concurrently captures the pointer before driver-core cleanup, followed by useful slab reuse. An unprivileged attacker cannot directly control both sides of this race.
PR:LPrivileges required, low: On a device whose firmware topology already produces the failure, no capability check protects the automatic probe path, and an unprivileged local process can attempt heap grooming and timing manipulation. User namespaces cannot directly create or rebind these platform devices, but real-root privileges are not required for that exploitation role.
UI:NUser interaction, none: The kernel automatically enumerates and probes both devices through platform-bus workqueues. No victim action such as opening a file, mounting something, or attaching a peripheral is required.
S:UScope, unchanged: The vulnerable driver and the affected kernel memory share the same operating-system security authority. This is not a VM escape, IOMMU bypass, or other scope-changing boundary crossing.
C:HConfidentiality impact, high: The freed object contains kernel pointers and may be replaced by another kmalloc object before stale accesses occur. Exploitable UAF reuse can provide kernel-memory disclosure, so confidentiality impact is High.
I:HIntegrity impact, high: cros_ec_check_features() can copy an eight-byte EC feature response into the freed object, corrupting any replacement object occupying that slab slot. Heap shaping could turn this write-after-free into control-flow corruption or kernel code execution.
A:HAvailability impact, high: The observed write-after-free occurs in a kernel workqueue and can produce an oops or panic. It can also disrupt device initialization or repeatedly prevent a vulnerable system from completing a reliable boot.