CVE-2026-64420: mfd: cros_ec: Delay dev_set_drvdata() until probe success
In the Linux kernel, the following vulnerability has been resolved:
mfd: crosec: Delay devsetdrvdata() until probe success
If ecdeviceprobe() fails, crosecclassrelease releases memory for the crosecdev structure. However, because the drvdata was already set, sub-drivers like crosectypec can still retrieve the stale pointer via the platform device. This leads to a use-after-free when crosectypec attempts to access &typec->ec->ec->dev on a device that has already been released. Move devsetdrvdata() to ensure that the pointer is only made available once all initialization steps have succeeded.
sysfs: cannot create duplicate filename '/class/chromeos/crosec' Call trace: sysfsdocreatelinksd+0x94/0xdc sysfscreatelink+0x30/0x44 deviceaddclasssymlinks+0x90/0x13c deviceadd+0xf0/0x50c ecdeviceprobe+0x150/0x4f0 platformprobe+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]=OOTMODULE Hardware name: Google Navi unprovisioned 0x7FFFFFFF/sku0 board/sku3 Workqueue: eventsunbound deferredprobeworkfunc Call trace: memcpy+0x44/0x230 croseccheckfeatures+0x60/0xcc [crosecproto] crostypecprobe+0xe8/0x6e0 [crosectypec] platformprobe+0xa0/0xe0
Affected Software
Remediation
Event History
Frequently Asked Questions
What conditions are needed to trigger the issue?
The failure path requires ec_device_probe() to fail after driver data has been made available. A sub-driver such as cros_ec_typec can then retrieve the stale platform-device pointer and access memory that has already been released.
Is this remotely exploitable?
The supplied CVSS vector identifies local attack access, low privileges required, no user interaction, and high impact to confidentiality, integrity, and availability. The provided information does not describe a network-reachable attack path.
What should be done to remediate it?
Apply an available patch that delays dev_set_drvdata() until initialization has succeeded. The listed stable kernel references provide the corresponding fixes.
How might affected systems present before a fix is applied?
The reported failure can include a duplicate sysfs filename error for /class/chromeos/cros_ec, followed by KASAN invalid-access reports during deferred probe work. The described access is a use-after-free involving cros_ec_typec after the ChromeOS EC device is released.