CVE-2026-64420

What it actually does

This is a Linux kernel use-after-free in the ChromeOS Embedded Controller driver stack. During cros_ec device probing, driver-private data is made visible before probe completion; if ec_device_probe() later fails, the cros_ec_dev structure can be released while sub-drivers such as cros_ec_typec may still retrieve and dereference the stale pointer from the platform device. A successful exploit could cause kernel memory corruption and may allow a local, low-privileged attacker to crash the system or potentially gain elevated kernel privileges, although exploitation is high-complexity and appears dependent on specific hardware, driver state, and probe-failure conditions.

Why it matters to the business

Affected systems may experience unexpected kernel crashes, instability during device initialization, or, in a worst case, local privilege escalation that gives an attacker full control of the host. The issue is not known to be exploited in the wild, is not in the CISA Known Exploited Vulnerabilities catalog, and has a very low EPSS score, so operational urgency is lower than for actively exploited remote flaws; however, kernel vulnerabilities should still be addressed through normal patch cycles, especially on ChromeOS-derived, embedded, or Linux systems using cros_ec-related drivers.

How an attack unfolds

An attacker would first need local access to a vulnerable Linux system and enough capability to influence driver/module behavior, device probing, or repeated initialization paths involving the ChromeOS Embedded Controller subsystem. The attacker then attempts to cause ec_device_probe() to fail after driver-private data has already been published. Because the object may be freed on the failure path while still reachable through platform device driver data, a later cros_ec_typec or related sub-driver probe can dereference the stale pointer. If the attacker can shape timing and memory reuse reliably, the use-after-free may be turned into kernel memory corruption, potentially leading to denial of service or privilege escalation. In less controlled cases, exploitation is more likely to manifest as kernel warnings, KASAN reports, or crashes during deferred probing.

How to fix it

Apply the vendor-supplied Linux kernel update that includes the fix moving dev_set_drvdata() until after successful cros_ec probe initialization. If fixed package versions are not yet available from the distribution or device vendor, track the relevant stable kernel advisories and backports for the cros_ec MFD driver fix. As mitigations, restrict local shell access, limit the ability of untrusted users to load kernel modules or interact with device-management interfaces, avoid using out-of-tree cros_ec-related modules where possible, and disable unused cros_ec/cros_ec_typec functionality only if it is operationally safe for the platform.

How to confirm the fix worked

Confirm that the running kernel contains the patched cros_ec driver logic, either by verifying the distribution kernel version against vendor advisories or by checking that the relevant patch is present in the kernel source/package changelog. Validate that affected modules are updated and reloaded after reboot. On systems with KASAN or debug kernels, reproduce prior device-probe scenarios and confirm that duplicate cros_ec sysfs creation warnings and use-after-free reports no longer occur. Also verify that no stale vulnerable kernel remains bootable as the default entry in the bootloader.

Typical attack path

1. Obtain local execution on a vulnerable Linux system using the ChromeOS Embedded Controller driver stack.
2. Identify that cros_ec, cros_ec_proto, and cros_ec_typec or related sub-drivers are present or loadable.
3. Trigger or influence a probe-failure condition in ec_device_probe(), such as duplicate sysfs class creation or deferred probe behavior.
4. Cause a sub-driver to retrieve stale driver data from the platform device after the cros_ec_dev structure has been released.
5. Trigger dereference of the freed object through paths such as cros_typec_probe() or cros_ec_check_features().
6. Attempt to convert the resulting use-after-free into a kernel crash, memory disclosure, or privilege escalation by manipulating heap reuse and timing.

How to detect it

Review kernel logs, persistent journal entries, crash dumps, KASAN reports, and oops/panic records for evidence of cros_ec probe failures followed by stale-pointer or use-after-free activity. Key sources include dmesg, /var/log/kern.log, /var/log/messages, systemd-journald kernel facility logs, pstore/ramoops, kdump/vmcore analysis, and endpoint telemetry that records kernel module load events or kernel crashes. Look for repeated deferred probe activity involving cros_ec, cros_ec_proto, and cros_ec_typec; duplicate sysfs creation errors for /class/chromeos/cros_ec; KASAN invalid-access reports in __memcpy; and call traces involving ec_device_probe(), cros_typec_probe(), cros_ec_check_features(), platform_probe(), or deferred_probe_work_func. Because no public exploitation or named threat actor activity is indicated, detection should focus on anomalous local triggering, repeated crashes, and forensic evidence of kernel memory-corruption attempts rather than known external network indicators.

• sysfs: cannot create duplicate filename '/class/chromeos/cros_ec'
• BUG: KASAN: invalid-access in __memcpy
• cros_ec_check_features
• cros_typec_probe
• ec_device_probe
• cros_ec_typec
• cros_ec_proto
• deferred_probe_work_func
• platform_probe
• Workqueue: events_unbound deferred_probe_work_func
• /class/chromeos/cros_ec

What your security team should do

• Inventory Linux and ChromeOS-derived systems that include or load cros_ec, cros_ec_proto, cros_ec_typec, or related ChromeOS Embedded Controller drivers.
• Prioritize patching on endpoints, appliances, development boards, and embedded systems where untrusted users can obtain local access.
• Apply vendor kernel updates when available and reboot systems to activate the fixed kernel.
• Restrict local privilege boundaries: prevent untrusted users from loading kernel modules, accessing debugfs/sysfs interfaces unnecessarily, or controlling device-probe behavior.
• Monitor kernel logs for KASAN use-after-free reports, cros_ec probe failures, cros_ec_typec probe crashes, and duplicate sysfs class creation messages.
• Treat crashes involving cros_ec_typec, cros_ec_check_features, or deferred_probe_work_func as potentially security-relevant until patched and investigated.
• If using custom or out-of-tree kernels, ensure the upstream cros_ec probe-ordering fix is manually backported and tested.