Back to CVE records
Not yet scoredPublished Sep 24, 2026

CVE-2026-93247Bluetooth: mgmt: fix 'hdev->discovery.uuids' NULL dereference

Updated under an hour ago ()

Does this affect you?

It affects Linux. Add what you run to find out whether that includes you.

No exploitation reported and no EPSS estimate yet.

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 ]---

CVSS
Not yet scored
Weakness (CWE)
Not given
Known exploited
Not in CISA's KEV catalog
EPSS (exploitation in the next 30 days)
Not loaded for this CVE
Assigned by
Linux
NVD analysis
Received
Record last updated
Sep 24, 2026
First seen by InfoSec Signals
Oct 9, 2026

Affected products

Affected products
Linux Linux
linux:linux (from the name)
from 86f3dcd1f331cfd4fd7ec88906955134ec51afbe before f02c01ccd12cb2b8a290077d4c90f29a6e109b16; from 7ce9bb0b95fc280e9212b8922590c492ca1d9c39 before bbd262d2d750b67b15a5e1008d3848309c87e7a7; 16852eccbdfaf41a666705e3f8be55cf2864c5ca builds before 18fda026a13c5abd6c1e0dfd3549f490b73378fb; from 2935e556850e9c94d7a00adf14d3cd7fe406ac03 before c3f63610bceaa182e4683b23cc47baf36b5f1496; from 2935e556850e9c94d7a00adf14d3cd7fe406ac03 before ee2135a14fb2a3e176149122764d293f0796b1eb; 2935e556850e9c94d7a00adf14d3cd7fe406ac03 builds before 59eecbe2f2f38d8f3e1104bd11da97f9a2c58998; a351ff6b8ecca4229afaa0d98042bead8de64799; f8069f34c4c976786ded97498012225af87435d7; and 5 more ranges
CNA record

References

The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.

Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.