CVE-2026-46134

What it actually does

This is a local denial-of-service flaw in the Linux kernel Chrome OS Embedded Controller Type-C driver path. The Thunderbolt alternate-mode registration routine fails to initialize a mutex before later code attempts to acquire it, for example during Type-C alternate-mode work handling. On affected systems, triggering the vulnerable code path can cause a NULL pointer dereference in kernel context, resulting in a kernel oops, panic, or system crash. The impact is availability only; the provided CVSS vector indicates local access with low attack complexity and low privileges, with no confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can crash affected Linux systems that use the vulnerable Chrome OS EC Type-C/Thunderbolt driver functionality, causing service interruption, endpoint instability, user downtime, or operational disruption. Because exploitation requires local access and the issue is not listed in CISA KEV, has no known ransomware association, and has very low EPSS, broad internet-scale exploitation is unlikely; however, systems where untrusted local users or workloads can interact with relevant Type-C/Thunderbolt functionality should still be prioritized for kernel updates.

How an attack unfolds

An attacker must first obtain local access to an affected Linux system with the vulnerable cros_ec_typec Thunderbolt registration code present and reachable. The attacker then causes the system to enter or exercise the Type-C Thunderbolt alternate-mode handling path where cros_typec_register_thunderbolt() has created state without initializing the associated mutex. When asynchronous alternate-mode work later attempts to acquire that mutex, the kernel dereferences a NULL or uninitialized lock pointer/state and crashes. The practical result is a local denial of service rather than code execution or data theft.

How to fix it

Update the Linux kernel to a vendor-supported build that includes the fix initializing the mutex in cros_typec_register_thunderbolt(). Because fixed versions were not provided in the input, use the relevant distribution or hardware vendor advisory to identify the first fixed kernel package for each platform. If immediate patching is not possible, reduce exposure by limiting local shell access to trusted users, restricting untrusted workloads, disabling or avoiding vulnerable Thunderbolt/USB Type-C alternate-mode functionality where operationally feasible, and applying existing hardening around Thunderbolt/USB4 device authorization. Mitigations should be treated as temporary because the durable fix is a patched kernel.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package is at or above the vendor-fixed version and that the system has been rebooted into the patched kernel, not merely installed it. Review vendor kernel changelogs or source patches for the fix that initializes `adata->lock` in `cros_typec_register_thunderbolt()`. On representative hardware, validate normal USB Type-C/Thunderbolt alternate-mode behavior without kernel oops or panic messages. Exposure can be assessed by checking whether affected kernel versions are deployed and whether the relevant Chrome OS EC Type-C driver/module is present, built in, or loaded on systems with applicable hardware.

Typical attack path

1. Gain local access to an affected Linux system, typically as a low-privileged user or local process.
2. Identify that the system is running a vulnerable kernel build with the Chrome OS EC Type-C/Thunderbolt driver path enabled or loaded.
3. Trigger Thunderbolt or USB Type-C alternate-mode registration/handling so the vulnerable cros_typec_register_thunderbolt() path is exercised.
4. Cause or wait for cros_typec_altmode_work() or related alternate-mode work to acquire the uninitialized mutex.
5. The kernel encounters a NULL pointer dereference and the system oopses, panics, hangs, or reboots, causing denial of service.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, persistent journal entries, crash dumps, kdump/vmcore data, system reboot records, and endpoint telemetry for crashes tied to the Chrome OS EC Type-C/Thunderbolt driver. Relevant sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, pstore/ramoops records, kdump output, and crash reporting systems such as ABRT or apport where applicable. Look for kernel oops, panic, NULL pointer dereference, general protection fault, or workqueue crash entries mentioning `cros_ec_typec`, `cros_typec_register_thunderbolt`, `cros_typec_altmode_work`, Thunderbolt registration, Type-C alternate mode, or mutex locking. Correlate crash times with local user logins, device attach/detach events, Thunderbolt authorization events, USB Type-C events, and sudden reboot records. Because no public exploit maturity or known threat actors are reported and this is a local DoS, detections should focus on repeated or suspiciously timed local crash patterns rather than network indicators.

• cros_typec_register_thunderbolt
• cros_typec_altmode_work
• cros_ec_typec
• NULL pointer dereference
• kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• general protection fault
• unable to handle kernel NULL pointer dereference
• Workqueue:
• Thunderbolt
• typec
• altmode
• mutex_lock
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• /sys/fs/pstore
• /var/crash

What your security team should do

• Inventory Linux systems, especially Chrome OS EC, Chromebook-derived, embedded, laptop, or workstation platforms with USB Type-C/Thunderbolt support, for vulnerable kernel versions.
• Patch affected systems with vendor-fixed kernel updates and ensure a reboot into the fixed kernel is completed.
• Prioritize systems with untrusted local users, shared workstations, kiosk-style deployments, developer endpoints, or multi-user compute environments where local denial-of-service risk is higher.
• Temporarily restrict local access and untrusted workload execution on systems that cannot be patched promptly.
• Monitor kernel logs and crash telemetry for NULL pointer dereferences, oopses, or panics involving cros_ec_typec, cros_typec_register_thunderbolt, cros_typec_altmode_work, or Type-C alternate-mode handling.
• Do not treat this as a remote compromise indicator by itself; focus response on availability impact unless additional suspicious activity is present.