CVE-2026-19937
MediumCVSS 5.7Summary
A vulnerability in the Bluetooth Mesh stack in Zephyr causes a permanent loss of message contexts from the pool, leading to denial of service (DoS) after pool exhaustion. An attacker in the mesh network can intentionally trigger context leaks, and the device stops responding to requests until reboot.
Risk Assessment
The organization faces persistent unavailability of mesh devices (e.g., sensors, lighting) after a DoS attack from the mesh network. The attack does not require physical access and can be performed remotely by a provisioned node, disrupting IoT infrastructure.
Recommendation
Apply the vendor patch (Zephyr) immediately, and if possible, disable delayed messages (CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG) or increase pool limits to reduce exhaustion risk. Monitor devices for lack of responses and plan reboot after incidents.
Other vulnerabilities in Zephyr Bluetooth Mesh
See all- CVE-2026-15894High
A vulnerability in the Zephyr Bluetooth Mesh stack affects the Solicitation PDU handler in sol_pdu_decrypt(). Received PDU is copied into a fixed 17-byte stack buffer without length checking, leading to stack overflow in production builds where assertions are disabled. An attacker can send a crafted advertisement to trigger out-of-bounds write without any cryptographic keys.
- CVE-2026-5589Medium
An integer underflow in bt_mesh_sol_recv() in the Bluetooth Mesh solicitation handling leads to an out-of-bounds write. When CONFIG_BT_MESH_OD_PRIV_PROXY_SRV is enabled, the function parses solicitation PDUs from raw BLE advertising payloads. The AD parsing loop reads an attacker-controlled length byte and computes reported_len - 3 without checking that reported_len >= 3. When reported_len is less than 3, the subtraction yields a negative value that bypasses the length guard and is then implicitly converted to a very large size_t when passed to net_buf_simple_pull_mem(). In builds without assertions, this wraps the buffer length and advances the data pointer far out of bounds, so subsequent reads dereference invalid memory. A nearby BLE device can trigger this with a non-connectable advertisement carrying a UUID16 AD structure and a crafted length byte, with no pairing or prior association required, potentially leading to denial of service or arbitrary code execution.
Original NVD description (English source)
The Bluetooth Mesh Access layer delayable-message machinery in subsys/bluetooth/mesh/delayable_msg.c manages a static pool of CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_COUNT message contexts (default 4) threaded onto a free_ctx or busy_ctx list. release_delayable_msg_ctx() returned a context to free_ctx only when sys_slist_find_and_remove() found it on busy_ctx. The chunk-exhaustion error path in bt_mesh_delayable_msg_manage() releases a context that was already popped off free_ctx but not yet inserted on busy_ctx, so the context was appended to neither list and was permanently lost from the pool. Because bt_mesh_delayable_msg_init() runs only once from bt_mesh_init(), and node reset/suspend only drain busy_ctx, the loss survives unprovision, re-provision and suspend/resume — it is cleared only by a reboot. The error path is reached when the chunk pool (CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CHUNK_COUNT, default 40 chunks) is short of the chunks a new delayed message needs and the oldest pending message cannot be flushed because bt_mesh_access_send() returns -EBUSY or -ENOBUFS (all segmented-TX contexts busy, or advertising/segment buffers exhausted). A peer that is provisioned into the mesh network — holding a valid NetKey plus an AppKey or DevKey bound to a server model — can drive both conditions by flooding the victim with requests that elicit segmented responses while withholding the Segment Acknowledgment, which keeps the transmit contexts occupied while queued responses hold the chunk pool. Each further request that arrives in that window leaks one context. Once the pool is drained, bt_mesh_delayable_msg_manage() returns -ENOMEM for every subsequent send and bt_mesh_model_send() propagates that error with no fallback to an immediate transmit. Since CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED are both enabled by default, ctx->rnd_delay is set for every received access message, so all replies from Configuration Server, Health Server and application server models are silently dropped. The node keeps receiving and processing traffic but never answers, a persistent denial of service until the device is restarted. There is no memory corruption, information disclosure or integrity impact; releases before the fix compute the chunk count from the transmit buffer capacity rather than its payload length, making chunk-pool starvation — and therefore the leak — considerably easier to provoke.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS