CVE-2026-46134: platform/chrome: cros_ec_typec: Init mutex in Thunderbolt registration
In the Linux kernel, the following vulnerability has been resolved:
platform/chrome: crosectypec: Init mutex in Thunderbolt registration
crostypecregisterthunderbolt() missed initializing the adata->lock mutex. This leads to a NULL dereference when the mutex is later acquired (e.g. in crostypecaltmodework()).
Initialize the mutex in crostypecregisterthunderbolt() to fix the issue.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Initialize the adata->lock mutex in cros_typec_register_thunderbolt() so it is initialized before being acquired by cros_typec_altmode_work()
platform/chrome: cros_ec_typec adata->lock = initialized mutex
Event History
Frequently Asked Questions
What access does an attacker need to trigger this issue?
The CVSS vector indicates local access and low privileges are required. No user interaction is required.
What is the likely impact if the flaw is triggered?
The issue can cause a NULL pointer dereference when the uninitialized mutex is acquired, resulting in a denial of service. The CVSS vector rates availability impact as high, with no confidentiality or integrity impact.
Where in the kernel does the failure occur?
The uninitialized adata->lock mutex is associated with Thunderbolt registration in the Chrome OS embedded-controller Type-C driver. A later path such as cros_typec_altmode_work() can acquire the mutex and trigger the NULL dereference.