CVE-2026-93247: Bluetooth: mgmt: fix 'hdev->discovery.uuids' NULL dereference
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: mgmt: fix 'hdev->discovery.uuids' NULL dereference
'uuidcount' member of struct 'discoverystate' is assigned and read without any locks, so there is a chance of situation when uuidcount != 0, but uuids is NULL and there will be NULL pointer dereference.
Possible race: 'hciupdatepassivescansync' 'hcidiscoveryfilterclear' hdev->discovery.uuidcount = 0; <----------------------preempted-----------------------------> 'startservicediscovery' // Set uuidcount to value != 0 hdev->discovery.uuidcount = uuidcount; hdev->discovery.uuids = kmemdup(...); <----------------------preempted-----------------------------> spinlock(&hdev->discovery.lock); kfree(hdev->discovery.uuids); hdev->discovery.uuids = NULL; spinunlock(&hdev->discovery.lock);
Now uuids == NULL and uuidcount != 0. So 'mgmtdevicefound' -> 'isfiltermatch' -> 'eirhasuuids' receives non consistent discovery state, where NULL dereference of uuids happens.
To fix it let's add discovery.lock around every read/write of uuidcount, uuids pair of struct members. It is also important to assign uuidcount value only after success kmemdup() allocation in startservicediscovery(), otherwise uuids is NULL, because kmemdup failed, but uuidcount 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 hcirxwork [ ] pstate: 10400009 (nzcV daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : eirhasuuids+0x2d8/0x590 [ ] lr : isfiltermatch+0x258/0x320 ... [ ] Call trace: [ ] eirhasuuids+0x2d8/0x590 [ ] isfiltermatch+0x258/0x320 [ ] mgmtdevicefound+0x5b0/0xafc [ ] processadvreport.part.0+0x8c8/0xf14 [ ] hcileadvreportevt+0x338/0x3f0 [ ] hcilemetaevt+0x1f0/0x4c8 [ ] hcieventpacket+0x440/0xc9c [ ] hcirxwork+0x44c/0xaf8 [ ] processonework+0x54c/0x103c [ ] workerthread+0x6c4/0x10c4 [ ] kthread+0x274/0x2ec [ ] retfromfork+0x10/0x20 [ ] Code: 14000004 91004021 eb14003f 54000180 (f9400024) [ ] ---[ end trace 0000000000000000 ]---
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the Linux kernel Bluetooth management discovery code, protect every read and write of hdev->discovery.uuid_count with discovery.lock, and assign a nonzero uuid_count only after kmemdup() successfully allocates hdev->discovery.uuids so the uuids and uuid_count members remain consistent.
Event History
Frequently Asked Questions
What conditions are required to trigger the crash?
The issue requires a race between Bluetooth discovery-state operations that leaves uuid_count nonzero while the uuids pointer is NULL. A device-found event can then reach the UUID filter matching path and dereference the NULL pointer.
What is the practical impact of successful triggering?
The described outcome is a NULL pointer dereference in the Linux kernel's Bluetooth management discovery handling. The provided information supports a crash or denial-of-service impact; it does not describe code execution or data disclosure.
What changes does the fix make?
The fix protects reads and writes of the discovery uuid_count and uuids pair with discovery.lock, preventing consumers from observing inconsistent state. It also assigns uuid_count only after the UUID array allocation succeeds.