CVE-2026-19937 in Zephyr
Summary
by MITRE • 10/13/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability resides in the Bluetooth Mesh Access layer implementation within the subsys/bluetooth/mesh/delayable_msg.c module, specifically affecting the management of delayable message contexts. The system relies on a static pool of message contexts, with the default configuration supporting four contexts threaded onto either free_ctx or busy_ctx lists to manage asynchronous operations. A critical logic error exists in the release_delayable_msg_ctx function and its interaction with bt_mesh_delayable_msg_manage. Under normal operation, when a delayed message is processed, it transitions from being allocated to pending status. However, an error path triggered by chunk pool exhaustion fails to correctly reinsert the context back into the free list if the context was popped off but not yet fully committed to the busy state. This results in the permanent loss of that specific memory context from the available pool. Because this initialization routine runs only once during system boot via bt_mesh_init, and because node reset or suspend procedures do properly drain active contexts, this leak persists across unprovisioning, re-provisioning events, and power cycles. The resource is effectively lost until a full device reboot occurs, making it a persistent state corruption issue rather than a transient error.
The conditions that trigger this vulnerability involve the exhaustion of the chunk pool used for segmented transmission buffers. When the system attempts to queue a new delayed message but finds insufficient chunks available in CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CHUNK_COUNT, and simultaneously cannot flush older pending messages due to busy transmit contexts or exhausted advertising buffers, it enters an error state. In this specific scenario, the code path incorrectly handles context release, leading to the leak described above. An attacker who is provisioned into the mesh network with valid Network Keys and Application or Device Keys bound to server models can exploit this by flooding the victim node with requests that require segmented responses. By strategically withholding Segment Acknowledgments, the attacker ensures that transmit contexts remain occupied while queued responses continue to hold chunk pool resources. Each subsequent request arriving during this window causes one additional context to be leaked from the pool. This technique leverages the resource management flaw to systematically deplete the available message handling capacity of the target device.
The operational impact of exhausting these delayable message contexts is a persistent denial of service for all delayed responses. Once the pool is drained, subsequent calls to send functions return -ENOMEM errors. Crucially, there is no fallback mechanism to transmit messages immediately when delayable transmission fails. Since both CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED are enabled by default in most configurations, every received access message triggers the setting of a random delay for its response. Consequently, replies from critical models such as Configuration Server, Health Server, and application-specific servers are silently dropped. The node continues to receive and process incoming traffic but fails to generate any responses. This creates a state where the device appears online and active in network discovery protocols but is functionally unresponsive to control or diagnostic commands. Unlike vulnerabilities involving memory corruption or information disclosure, this issue strictly impacts availability by rendering the node incapable of performing its intended mesh networking duties until it is manually restarted.
From a classification perspective, this vulnerability aligns with CWE-401: Missing Release of Memory after Effective Lifetime and CWE-772: Missing Release of Resource after Effective Lifetime. The failure to return allocated resources to their respective pools upon error conditions leads to resource exhaustion over time. In terms of the MITRE ATT&CK framework for IoT, this behavior corresponds to T1499: Endpoint Denial of Service, specifically through resource exhaustion techniques that target application-layer services rather than network bandwidth or compute cycles directly. Mitigation strategies primarily involve applying vendor-provided firmware updates that correct the logic in release_delayable_msg_ctx and bt_mesh_delayable_msg_manage to ensure contexts are always returned to the free list regardless of error paths during chunk allocation failures. For environments where immediate patching is not feasible, reducing CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CHUNK_COUNT may alter the timing but does not resolve the underlying leak; therefore, monitoring for abnormal response latencies or implementing network-level rate limiting on segmented request traffic can help mitigate the risk until a software fix is deployed.