CVE-2026-64420 Overview
CVE-2026-64420 is a use-after-free vulnerability in the Linux kernel's ChromeOS Embedded Controller (cros_ec) multi-function device (MFD) driver. The flaw exists because dev_set_drvdata() is called before ec_device_probe() completes successfully. If probe fails, cros_ec_class_release frees the cros_ec_dev structure, but sub-drivers such as cros_ec_typec can still retrieve the stale pointer through the platform device. Subsequent access to &typec->ec->ec->dev operates on freed memory, triggering kernel memory corruption detected by KASAN with Memory Tagging Extension (MTE).
Critical Impact
A local attacker with the ability to trigger driver probe failures can exploit the use-after-free to corrupt kernel memory, potentially leading to privilege escalation or denial of service on affected ChromeOS-based systems.
Affected Products
- Linux kernel versions containing the mfd: cros_ec driver prior to the fix
- ChromeOS platforms using the cros_ec_typec sub-driver
- Google ChromeOS hardware (Navi board referenced in the reported crash trace)
Discovery Timeline
- 2026-07-25 - CVE-2026-64420 published to the National Vulnerability Database (NVD)
- 2026-07-27 - Last updated in NVD database
Technical Details for CVE-2026-64420
Vulnerability Analysis
The vulnerability resides in the mfd: cros_ec driver initialization sequence. The driver calls dev_set_drvdata() early during probe, which registers the cros_ec_dev pointer on the platform device before initialization completes. When ec_device_probe() later fails, for example due to a duplicate sysfs filename /class/chromeos/cros_ec, the class release callback cros_ec_class_release frees the cros_ec_dev structure.
The deferred probe workqueue continues invoking sub-driver probes, including cros_typec_probe. That path retrieves the freed pointer via the platform device's drvdata field and calls cros_ec_check_features(), which performs __memcpy on the released memory region. The KASAN report shows a pointer tag mismatch ([f5] versus memory tag [fe]), confirming access to memory that has been reclaimed.
Root Cause
The root cause is incorrect ordering of driver data registration relative to initialization completion. Storing the cros_ec_dev pointer via dev_set_drvdata() before all probe steps succeed exposes freed memory to sub-drivers when probe fails. This is a classic use-after-free condition where object lifetime is not synchronized with pointer publication.
Attack Vector
Exploitation requires local access with low privileges on an affected ChromeOS system. An attacker must trigger conditions that cause ec_device_probe() to fail after dev_set_drvdata() has been called, such as inducing a duplicate class registration. The high attack complexity reflects the timing sensitivity required to race the deferred probe workqueue against the class release callback. Successful exploitation corrupts kernel heap memory and may enable privilege escalation.
The kernel patch relocates dev_set_drvdata() so the drvdata pointer is only published after all initialization steps succeed. See the fix commits linked in the Linux Kernel Commit Update for the exact code changes.
Detection Methods for CVE-2026-64420
Indicators of Compromise
- Kernel log entries reporting sysfs: cannot create duplicate filename '/class/chromeos/cros_ec' followed by sub-driver probe activity
- KASAN invalid-access reports referencing __memcpy, cros_ec_check_features, or cros_typec_probe
- Unexpected kernel panics or oops events tied to the events_unbound workqueue running deferred_probe_work_func
Detection Strategies
- Enable KASAN and MTE on test builds to surface use-after-free access in the cros_ec code paths
- Monitor dmesg and persistent kernel crash logs for tracebacks originating in cros_ec_proto or cros_ec_typec modules
- Correlate driver probe failures with subsequent memory corruption reports on ChromeOS device fleets
Monitoring Recommendations
- Ingest kernel crash telemetry and syslog into a centralized log platform for pattern matching on the traceback signature
- Track running kernel versions across the fleet and flag hosts on unpatched builds of the cros_ec driver
- Alert on repeated deferred probe failures involving ChromeOS embedded controller drivers
How to Mitigate CVE-2026-64420
Immediate Actions Required
- Apply the upstream Linux kernel patches that reorder dev_set_drvdata() to run only after successful probe completion
- Update affected ChromeOS systems to a kernel build that includes the fix commits referenced by kernel.org stable
- Restrict local, unprivileged access on multi-user ChromeOS devices to reduce the pool of potential attackers
Patch Information
Fixes are available across multiple Linux stable branches. Refer to the upstream commits: 24522713034d, 257203d83204, 729ae27dc250, 8b2c1d41bc36, b5f41d5bf08e, ed2941e5db01, f7e81dc181d9, and fc030c5b116f. Rebuild and redeploy kernels with the appropriate stable backport for your distribution.
Workarounds
- Unload the cros_ec_typec module on systems where it is not required to prevent the vulnerable code path from executing
- Disable ChromeOS embedded controller sub-drivers via kernel module blacklisting where hardware functionality is not needed
- Enforce least-privilege user access policies to limit local users capable of manipulating driver probe conditions
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
