Description
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.
Published: 2026-10-12
Score: 5.7 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service
Action: Apply Patch
AI Analysis

Impact

A flaw in the Bluetooth Mesh Access layer causes delayable-message contexts to leak permanently from a static pool. The missing contexts lead to repeated send failures and cause all model responses to silently drop. The issue is a resource‑management weakness (CWE‑772) that results only in denial of service; there is no memory corruption or data disclosure. The vulnerability is exploitable only by a device that is already provisioned into a mesh network and can flood the target with segmented requests while withholding acknowledgment messages, driving the pool to exhaustion and disabling replies until a system reboot restores the context pool. Based on the description, it is inferred that the attack requires network proximity and valid provisioning credentials.

Affected Systems

The affected system is the Zephyr RTOS (zephyrproject:zephyr). The issue exists in all builds where CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED are enabled, which is the default configuration. No specific product version is listed, but the problem is present whenever the static delayable‑message context pool is used.

Risk and Exploitability

The CVSS score is 5.7, indicating a medium severity impact. The EPSS score is not available and the vulnerability is not listed in the CISA KEV catalog. Nonetheless, an attacker who can reach the affected node over the mesh network can trigger the vulnerability by flooding it with segmented requests and withholding acknowledgments, creating a persistent denial of service that survives node reset, suspend or resumption of operation. The most likely attack vector is via an in‑mesh, authenticated, provisioned neighbor that has the capacity to generate segmented messages. The vulnerability is exploitable without special hardware or software beyond mesh protocol compliance. Due to the absence of exploitable memory corruption or data leakage, the risk is limited to disruption of functionality rather than compromise of confidentiality or integrity.

Generated by OpenCVE AI on October 13, 2026 at 00:58 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade Zephyr to a version that contains the fix (the commit 097001f or a later release).
  • If an upgrade is not immediately possible, configure the device to reboot automatically after detecting sustained evidence of delayed message context exhaustion—implement a watchdog timer or monitor the bt_mesh_delayable_msg_manage() return values.
  • Disable or limit the usage of delayable messages by setting CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_COUNT to 0 or reducing the count if the application does not rely on delayable responses, and enforce stricter rate limiting on segmented requests from peer nodes.

Generated by OpenCVE AI on October 13, 2026 at 00:58 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 14 Oct 2026 20:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Tue, 13 Oct 2026 02:15:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Mon, 12 Oct 2026 23:30:00 +0000

Type Values Removed Values Added
Description 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.
Title Bluetooth Mesh Access layer permanently leaks delayable-message contexts, disabling all model responses
Weaknesses CWE-772
References
Metrics cvssV3_1

{'score': 5.7, 'vector': 'CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

Subscriptions

Zephyrproject Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-10-14T19:17:03.644Z

Reserved: 2026-08-15T13:31:18.438Z

Link: CVE-2026-19937

cve-icon Vulnrichment

Updated: 2026-10-14T19:16:59.613Z

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-10-13T00:17:01.533

Modified: 2026-10-14T20:17:35.543

Link: CVE-2026-19937

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-13T02:00:08Z

Weaknesses
  • CWE-772

    Missing Release of Resource after Effective Lifetime