CVE-2026-93247 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: mgmt: fix 'hdev->discovery.uuids' NULL dereference
'uuid_count' member of struct 'discovery_state' is assigned and read without any locks, so there is a chance of situation when uuid_count != 0, but uuids is NULL and there will be NULL pointer dereference.
Possible race: 'hci_update_passive_scan_sync' 'hci_discovery_filter_clear' hdev->discovery.uuid_count = 0; <----------------------preempted-----------------------------> 'start_service_discovery' // Set uuid_count to value != 0 hdev->discovery.uuid_count = uuid_count; hdev->discovery.uuids = kmemdup(...); <----------------------preempted-----------------------------> spin_lock(&hdev->discovery.lock); kfree(hdev->discovery.uuids); hdev->discovery.uuids = NULL; spin_unlock(&hdev->discovery.lock);
Now uuids == NULL and uuid_count != 0. So 'mgmt_device_found' -> 'is_filter_match' -> 'eir_has_uuids' receives non consistent discovery state, where NULL dereference of uuids happens.
To fix it let's add discovery.lock around every read/write of uuid_count, uuids pair of struct members. It is also important to assign uuid_count value only after success kmemdup() allocation in start_service_discovery(), otherwise uuids is NULL, because kmemdup failed, but uuid_count is already assigned to non zero value.
The following panic happens:
[ ] ------------[ cut here ]------------
[ ] Unable to handle kernel NULL pointer dereference at virtual
address 0000000000000000 [ ] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP
[ ] CPU: 0 PID: 15056 Comm: kworker/u9:2
[ ] Workqueue: hci0 hci_rx_work
[ ] pstate: 10400009 (nzcV daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ ] pc : eir_has_uuids+0x2d8/0x590
[ ] lr : is_filter_match+0x258/0x320
... [ ] Call trace:
[ ] eir_has_uuids+0x2d8/0x590
[ ] is_filter_match+0x258/0x320
[ ] mgmt_device_found+0x5b0/0xafc
[ ] process_adv_report.part.0+0x8c8/0xf14
[ ] hci_le_adv_report_evt+0x338/0x3f0
[ ] hci_le_meta_evt+0x1f0/0x4c8
[ ] hci_event_packet+0x440/0xc9c
[ ] hci_rx_work+0x44c/0xaf8
[ ] process_one_work+0x54c/0x103c
[ ] worker_thread+0x6c4/0x10c4
[ ] kthread+0x274/0x2ec
[ ] ret_from_fork+0x10/0x20
[ ] Code: 14000004 91004021 eb14003f 54000180 (f9400024)
[ ] ---[ end trace 0000000000000000 ]---
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel Bluetooth management subsystem contains a critical race condition vulnerability involving the discovery state structure, specifically affecting the integrity of the uuid_count and uuids members. This flaw arises from insufficient synchronization when accessing these fields across concurrent execution paths within the host controller interface layer. The core issue is that the uuid_count integer variable and the corresponding pointer to an array of UUID objects are modified without holding a dedicated spinlock in all code paths, leading to inconsistent state visibility between threads. When one thread updates the count while another reads it or accesses the associated memory buffer, the system can enter a state where the counter indicates active entries exist but the underlying data structure is nullified or not yet allocated. This inconsistency triggers a kernel panic due to an invalid memory access attempt on a NULL pointer during device discovery filtering operations.
The technical mechanism of this vulnerability involves specific functions within the Bluetooth management interface that handle passive scanning and service discovery updates. The race condition typically occurs when hci_update_passive_scan_sync or similar synchronization routines interact with hci_discovery_filter_clear and start_service_discovery. In a problematic sequence, one execution path may set uuid_count to zero while clearing filters, releasing locks, and then another thread invokes start_service_discovery which allocates memory for UUIDs via kmemdup and sets the count. However, if this allocation is followed by immediate deallocation in hci_discovery_filter_clear before subsequent reads occur, or if the order of operations between setting the count and assigning the pointer is not atomic with respect to other readers, a window opens where uuid_count remains non-zero while uuids becomes NULL. The function eir_has_uuids, which checks for UUID presence during device found events, blindly trusts the value in uuid_count without verifying that the corresponding array pointer is valid. Consequently, it attempts to dereference the nullified pointer, causing an immediate crash of the kernel workqueue processing Bluetooth receive events.
The operational impact of this vulnerability is severe, resulting in a denial of service against the local system running the affected Linux kernel version. The provided stack trace confirms that the fault occurs within eir_has_uuids called from is_filter_match and mgmt_device_found during the processing of LE advertising reports. This means any active Bluetooth scanning or device discovery operation can trigger the crash if the timing aligns with the race window. An attacker does not necessarily need to exploit this remotely; local access to Bluetooth interfaces combined with specific workload patterns involving rapid connection attempts, filter changes, and scan state updates is sufficient to reproduce the issue. The resulting kernel oops halts the hci_rx_work thread and potentially destabilizes the entire system depending on panic settings, effectively rendering Bluetooth functionality unusable until a reboot occurs. This represents a significant reliability risk for devices relying on continuous Bluetooth connectivity such as IoT hubs, automotive systems, or enterprise workstations with active peripheral scanning enabled.
Mitigation strategies focus primarily on patching the kernel to enforce strict atomicity and locking around shared state modifications. The definitive fix involves wrapping all read and write operations of the uuid_count and uuids pair within hdev->discovery.lock spinlock protection. This ensures that any thread checking for UUID presence sees a consistent snapshot where either both fields are valid or both indicate no active data. Additionally, the allocation logic in start_service_discovery must be adjusted to assign the new count value only after successful memory duplication via kmemdup. If allocation fails, the count should remain zero to prevent false positives that lead to null dereferences. System administrators unable to apply immediate kernel patches can mitigate risk by disabling unnecessary Bluetooth discovery services or restricting access to management interfaces if feasible. Long-term resilience requires adherence to secure coding practices for concurrent data structures in network stacks, ensuring that pointer validity is always verified against associated metadata under lock protection before any memory access occurs. This vulnerability aligns with CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization and can be mapped to ATT&CK techniques related to local privilege escalation or denial of service via resource exhaustion if the crash leads to system instability exploitable for further attacks.