CVE-2026-64420 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
mfd: cros_ec: Delay dev_set_drvdata() until probe success
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
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/25/2026
This vulnerability exists within the ChromeOS Embedded Controller (EC) subsystem of the Linux kernel, specifically in the multi-function device (MFD) framework where the cros_ec driver manages communication with ChromeOS EC devices. The flaw occurs during device probe operations when the driver attempts to set platform device driver data before all initialization steps have completed successfully. When ec_device_probe() fails, the cros_ec_class_release function cleans up memory for the cros_ec_dev structure, but because dev_set_drvdata() was already called earlier in the process, sub-drivers such as cros_ec_typec can still access stale pointers through the platform device. This creates a use-after-free condition where the typec driver attempts to access &typec->ec->ec->dev on a device that has already been released, leading to memory corruption and potential system instability.
The technical root cause involves improper ordering of operations within the device probe sequence where driver data is made available before all initialization steps have succeeded. According to CWE-415, this represents an improper handling of memory resources where a pointer becomes invalid while still being referenced by other components. The vulnerability manifests through kernel address sanitizer (KASAN) reporting an invalid memory access during memcpy operations, specifically showing that write operations occur at address f5ffff809e2d33ac by worker thread kworker/u32:5/125. The call trace demonstrates how cros_ec_check_features attempts to access the corrupted memory through cros_typec_probe which is part of the ATT&CK technique T1059.006 for execution through kernel modules, indicating that attackers could potentially exploit this to execute arbitrary code in kernel space.
The operational impact of this vulnerability extends beyond simple memory corruption to potentially enable privilege escalation and system compromise. When the use-after-free occurs, it creates an opportunity for malicious actors to manipulate kernel memory structures, potentially leading to full system takeover. The kernel's device management subsystem becomes unstable as stale pointers cause invalid memory accesses during subsequent driver operations. This particular flaw affects ChromeOS systems where the EC communicates with various subsystems including USB type-C controllers, battery management, and other embedded components that rely on proper driver initialization sequences. As a security vulnerability, it aligns with ATT&CK framework's T1068 which covers local privilege escalation through kernel exploits.
Mitigation strategies should focus on ensuring proper ordering of operations within the device probe mechanism to prevent premature exposure of driver data. The fix involves moving dev_set_drvdata() to occur only after all initialization steps have completed successfully, preventing sub-drivers from accessing stale pointers during failure conditions. System administrators should ensure timely kernel updates that include this patch to prevent exploitation. Additionally, monitoring for KASAN reports and memory corruption patterns in system logs can help detect potential exploitation attempts. The vulnerability also highlights the importance of proper resource management in kernel drivers, particularly those handling embedded controller communication where multiple subsystems depend on consistent device state. This fix addresses a fundamental issue in driver development practices where defensive programming principles should ensure that pointer validity is maintained throughout the entire initialization lifecycle rather than assuming all operations will succeed.