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

Impact

The vulnerability arises from an unsynchronized access to three intrusive lists and a work item between the Bluetooth host RX thread and the system workqueue. When an inbound mesh message is enqueued, the concurrent consumer can observe a torn list state, leading to a NULL pointer dereference in the delayable message handler. The outcome is a crash of the system workqueue thread, which stops all workqueue‑driven functionality and effectively renders the node unavailable. The attacker does not gain code execution or data exfiltration; the fault is deterministic and its location is fixed, so the primary impact is loss of availability.

Affected Systems

Vulnerable components reside in the Zephyr RTOS Bluetooth Mesh stack, specifically subsys/bluetooth/mesh/delayable_msg.c. The flaw exists in any Zephyr build that enables the default configuration options CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED, which are enabled by default. The affected vendor is Zephyr Project; no specific product version is listed beyond the default build configuration.

Risk and Exploitability

The CVSS score of 4.8 reflects moderate complexity due to the requirement of sensitive Bluetooth credentials and the need for a sustained traffic stream to hit the synchronization window. Because the EPSS score is not available and the vulnerability is not in the CISA KEV catalog, there is no evidence of widespread exploitation. Nevertheless, the flaw allows an authenticated peer—one that holds the NetKey and a bound AppKey—to flood the delayable message queue and trigger the fault. The likely attack vector is over‑the‑air Bluetooth Mesh traffic, with the attacker controlling the rate, payload size, and destination address.

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

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the Zephyr RTOS update that patches the delayable message queue by introducing synchronization with a k_spinlock and removing unchecked list access.
  • If an immediate update is not feasible, disable the delayable message queue by setting CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED to n in the Zephyr configuration.
  • After configuration changes or patch deployment, verify that no mesh traffic is being processed and restart the device to clear any lingering crashed workqueue state.

Generated by OpenCVE AI on October 13, 2026 at 00:34 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 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.
Title Bluetooth Mesh delayable message queue: unsynchronized list access leads to NULL pointer dereference
Weaknesses CWE-362
References
Metrics cvssV3_1

{'score': 4.8, 'vector': 'CVSS:3.1/AV:A/AC:H/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:16:26.893Z

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

Link: CVE-2026-19936

cve-icon Vulnrichment

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

cve-icon NVD

Status : Awaiting Analysis

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

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

Link: CVE-2026-19936

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

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

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')