CVE-2026-19936

MediumCVSS 4.8

Published: 13/10/2026(UTC)Updated: 14/10/2026(UTC)Translated: 13/10/2026(UTC)NVD NIST

Exploitation Probability (EPSS)

Low risk

0.14%

3th percentile - higher than 3% of all known CVEs

Summary

In the Bluetooth Mesh Access-layer delayable message queue (subsys/bluetooth/mesh/delayable_msg.c), three lists and one delayed work item are shared between two cooperative threads without synchronization. A missing NULL check after sys_slist_get() and a race between bt_mesh_delayable_msg_manage() and delayable_msg_handler() allow a read-modify-write through a NULL-based pointer, faulting the system workqueue thread or resetting the node. The flaw does not lead to memory corruption or code execution — the impact is loss of availability of the affected node.

Risk Assessment

An attacker who is a member of the mesh network (holding the NetKey and a bound AppKey) can exhaust the context and chunk pools, causing the system workqueue thread to fault or the node to reset. This results in loss of availability of mesh services on the affected device, including the mesh timing machinery.

Recommendation

Update Bluetooth Mesh devices to a version containing the fix that serializes list mutations with a k_spinlock, removes the unchecked sys_slist_get(), and drops messages when the stack is suspended or reset. If updating is not possible, consider disabling CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED if the functionality is not required.

Related vulnerabilities

Original NVD description (English source)

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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS