Linux Kernel EUVD-2026-86940

Exploitation requires local access to the system and the ability to trigger HCI device registration for a Bluetooth controller marked with quirks such as HCI_QUIRK_RAW_DEVICE, which sets the HCI_UNCONFIGURED flag. The bug is a narrow timing window in hci_register_dev() where the power_on work item runs on another CPU before hdev->msft_data's filter_lock mutex is initialized. Key limiting factors: it is local-only (AV:L), requires low privilege (PR:L), demands winning a high-complexity race (AC:H) that is hard to trigger reliably, affects only non-default quirk-flagged/unconfigured controllers, and primarily manifests on kernels built with lock debugging (DEBUG_LOCKS); impact is limited to availability with no confidentiality or integrity effect.

This is a low-to-moderate priority local availability issue, not a widespread remote threat. The CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) scores 4.7 (Medium) and tells a consistent story: an attacker needs local access and low privileges, must win a high-complexity race condition (CWE-362) during HCI device registration, and the only impact is availability (C:N/I:N) - a DEBUG_LOCKS warning or potential crash from locking an uninitialized mutex. EPSS is very low at 0.17% (5th percentile), it is NOT on the CISA KEV list, and no public exploit code is referenced, so there is no public exploit identified at time of analysis. All real-world exploitation signals (low EPSS, no KEV, no POC, high attack complexity, local-only vector) align and point to low practical risk. One conflict to note: the input Tags list 'Information Disclosure,' but the CVSS vector explicitly sets C:N/I:N/A:H, meaning this is an availability/denial-of-service bug, not an information-disclosure one - the tag appears mislabeled and should not drive triage. Patch availability is confirmed via multiple git.kernel.org stable commits, so remediation is straightforward through normal kernel updates.

A local low-privileged user triggers Bluetooth HCI device registration for a device flagged with quirks such as HCI_QUIRK_RAW_DEVICE and races the asynchronous power_on work item against msft_register(). If the power_on path (via hci_dev_do_close → msft_do_close) runs before mutex_init() on filter_lock completes, it locks an uninitialized mutex, producing a DEBUG_LOCKS warning and potential instability. No public exploit code exists, and the high timing-dependency of the race makes reliable triggering difficult.