Zephyr Project up to 4.4.2 Bluetooth Mesh Access delayable_msg.c bt_mesh_delayable_msg_manage rnd_delay denial of service

Summaryinfo

A vulnerability classified as critical has been found in Zephyr Project Zephyr up to 4.4.2. This affects the function bt_mesh_delayable_msg_manage of the file subsys/bluetooth/mesh/delayable_msg.c of the component Bluetooth Mesh Access. The manipulation of the argument rnd_delay leads to denial of service. This vulnerability is listed as CVE-2026-19937. The attack may be initiated remotely. There is no available exploit. It is suggested to install a patch to address this issue.

Detailsinfo

A vulnerability was found in Zephyr Project Zephyr up to 4.4.2 and classified as critical. This issue affects the function bt_mesh_delayable_msg_manage of the file subsys/bluetooth/mesh/delayable_msg.c of the component Bluetooth Mesh Access. The manipulation of the argument rnd_delay with an unknown input leads to a denial of service vulnerability. Using CWE to declare the problem leads to CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use. Impacted is availability. The summary by CVE is:

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.

The advisory is shared at github.com. The identification of this vulnerability is CVE-2026-19937 since 08/15/2026. The exploitation is known to be easy. The attack may be initiated remotely. Technical details are known, but no exploit is available. MITRE ATT&CK project uses the attack technique T1499 for this issue.

Applying the patch 097001f187ba2764e9ef1cc7113b8da525bf741c is able to eliminate this problem.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Type

• Project Management Software

Vendor

• Zephyr Project

Name

• Zephyr

Version

• 4.4.0
• 4.4.1
• 4.4.2

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion