Odebrany

CVE-2026-93247

opublikowano: 24.09.2026, 18:17

modyfikacja: 24.09.2026, 18:17

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

Bluetooth: mgmt: napraw wyłuskiwanie wartości NULL „hdev->discovery.uuids”.

Element „uuid_count” struktury „discovery_state” jest przypisywany i odczytywany
bez żadnych zamków, więc istnieje szansa na sytuację, kiedy
uuid_count != 0, ale uuids ma wartość NULL i będzie wskaźnik NULL
wyłudzanie.

Możliwy wyścig:
„hci_update_passive_scan_sync”
„hci_discovery_filter_clear”
hdev->discovery.uuid_count = 0;
<--------------------------------uprzedzony ------------------------>
„start_service_discovery”
// Ustaw uuid_count na wartość != 0
hdev->discovery.uuid_count = uuid_count;
hdev->discovery.uuids = kmemdup(...);
<--------------------------------uprzedzony ------------------------>
spin_lock(&hdev->discovery.lock);
kfree(hdev->discovery.uuids);
hdev->discovery.uuids = NULL;
spin_unlock(&hdev->discovery.lock);

Teraz uuids == NULL i uuid_count != 0.
Zatem „mgmt_device_found” -> „is_filter_match” -> „eir_has_uuids” otrzymuje
niespójny stan wykrywania, w którym następuje dereferencja UUID o wartości NULL.

Aby to naprawić, dodajmy Discovery.lock przy każdym odczycie/zapisie uuid_count,
uuids para elementów struktury. Ważne jest również przypisanie uuid_count
wartość dopiero po pomyślnej alokacji kmemdup().
start_service_discovery(), w przeciwnym razie uuids ma wartość NULL, ponieważ kmemdup nie powiódł się,
ale uuid_count jest już przypisany do wartości niezerowej.

Występuje następująca panika:

[ ] ------------[wytnij tutaj ]------------
[ ] Nie można obsłużyć dereferencji wskaźnika NULL jądra w środowisku wirtualnym
adres 000000000000000
[ ] Błąd wewnętrzny: Ups: 0000000096000006 [#1] PREEMPT SMP
[ ] Procesor: 0 PID: 15056 Comm: kworker/u9:2
[ ] Kolejka robocza: hci0 hci_rx_work
[ ] pstan: 10400009 (nzcV daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ ] szt: eir_has_uuids+0x2d8/0x590
[ ] lr : is_filter_match+0x258/0x320
...
[ ] Śledzenie połączenia:
[ ] eir_has_uuids+0x2d8/0x590
[ ] is_filter_match+0x258/0x320
[ ] mgmt_device_found+0x5b0/0xafc
[ ] proces_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
[ ] proces_one_work+0x54c/0x103c
[ ] wątek_pracownika+0x6c4/0x10c4
[ ] kwątek+0x274/0x2ec
[ ] ret_from_fork+0x10/0x20
[ ] Kod: 14000004 91004021 eb14003f 54000180 (f9400024)
[ ] ---[koniec śledzenia 0000000000000000 ]---

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

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve