CVE-2026-19936

ŚrednieCVSS 4.8

Opublikowano: 13/10/2026(UTC)Zaktualizowano: 14/10/2026(UTC)Przetłumaczono: 13/10/2026(UTC)NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko

0.14%

Percentyl 3 - wyżej niż 3% wszystkich znanych CVE

Streszczenie

W kolejce komunikatów warstwy dostępu Bluetooth Mesh (subsys/bluetooth/mesh/delayable_msg.c) trzy listy i jedno zadanie opóźnione są współdzielone między dwoma wątkami kooperacyjnymi bez synchronizacji. Brak sprawdzenia NULL po sys_slist_get() oraz wyścig między bt_mesh_delayable_msg_manage() a delayable_msg_handler() pozwalają na odczyt-modyfikację-zapis przez wskaźnik NULL, co powoduje awarię wątku systemowej kolejki roboczej lub reset węzła. Luka nie prowadzi do uszkodzenia pamięci ani wykonania kodu — skutkiem jest utrata dostępności zaatakowanego węzła.

Ocena ryzyka

Atakujący będący członkiem sieci mesh (posiadający NetKey i powiązany AppKey) może wyczerpać pule kontekstów i fragmentów, doprowadzając do awarii wątku systemowej kolejki roboczej lub resetu węzła. Skutkuje to niedostępnością usług mesh na dotkniętym urządzeniu, w tym mechanizmów czasowych mesh.

Rekomendacja

Zaktualizuj urządzenia z Bluetooth Mesh do wersji zawierającej poprawkę, która serializuje mutacje list za pomocą k_spinlock, usuwa niesprawdzone sys_slist_get() i odrzuca komunikaty w stanie zawieszenia/resetu stosu. Jeśli aktualizacja nie jest możliwa, rozważ wyłączenie opcji CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG i CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED, jeśli funkcjonalność nie jest wymagana.

Powiązane podatności

Oryginalny opis (angielski, źródło NVD)

The Bluetooth Mesh Access-layer delayable message queue in subsys/bluetooth/mesh/delayable_msg.c shares three intrusive lists (busy_ctx, free_ctx, free_chunks) and one k_work_delayable between two cooperative threads with no synchronization: bt_mesh_delayable_msg_manage() runs on the Bluetooth host RX thread, while delayable_msg_handler() runs on the system workqueue. Both block while the lists are in an intermediate state — the enqueuer in bt_rand(), both in bt_mesh_access_send() — which lets the other context observe torn state. delayable_msg_handler() used the result of sys_slist_get() on busy_ctx without a NULL check, and allocate_delayable_msg_ctx() tested sys_slist_is_empty() and then assumed a separate sys_slist_get() would succeed. Because CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED default to y, every model response to a received mesh message is parked on this queue, so the enqueuer runs as a direct consequence of inbound traffic. A peer that can get access-layer messages accepted by a model (it must hold the NetKey and a bound AppKey, so a legitimate or compromised network member) controls the arrival rate, the size of the elicited responses and the destination address, and thereby controls occupancy of the 4-entry context pool and the 40-entry chunk pool. Exhausting the chunk pool forces bt_mesh_delayable_msg_manage() down the purge path, which sends and releases the only queued message and leaves busy_ctx empty while the delayable work item is still armed; if the enqueuer then yields, the handler runs against the empty list. The result is a read-modify-write through a NULL-based pointer (pending_msg->fired_time += 10) at a fixed low address on the system workqueue thread. On typical targets that faults, aborting the system workqueue thread — which stops all workqueue-driven functionality, including the mesh timing machinery — or resetting the node, so the impact is loss of availability of the affected node. The write value and address are fixed and no attacker-controlled length or index is involved, so this is not exploitable for memory corruption or code execution. The same unsynchronized window also allowed one message context to be selected and released by two contexts at once, producing duplicated transmissions, duplicated send-completion callbacks and crossed chunk ownership. The fix serializes every list mutation with a k_spinlock that is never held across a blocking call, makes push_msg_from_delayable_msgs() detach the queue head atomically so a message being sent is on no list, removes the unchecked sys_slist_get() from delayable_msg_handler(), and drops any message that reaches the front of the queue while the stack is suspended or reset.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS