Zephyr RTOS
CVE-2026-19936
MEDIUM
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessJoin mesh as credentialed member in radio range
-
DeliverySend crafted access-layer messages eliciting responses
-
ExploitExhaust 40-entry chunk pool forcing purge path
-
ExecutionWin race so handler hits empty busy_ctx
-
ImpactNULL-pointer write aborts workqueue, node DoS
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V15 - Secure Coding and Architecture Concurrency control, locking
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires both CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED (both default to 'y', so stock builds are affected) and a model that generates responses to inbound mesh messages. The attacker must be a provisioned, credentialed mesh network member - holding the NetKey and a bound AppKey - within Bluetooth radio range (Adjacent), able to control arrival rate, response size, and destination address to exhaust the 4-entry context pool and 40-entry chunk pool and drive the purge path. Limiting factors: valid mesh credentials are mandatory (PR:L, rules out anonymous attackers), physical/radio proximity is required (AV:A), and exploitation hinges on winning a narrow unsynchronized race where the enqueuer yields while busy_ctx is empty (AC:H), making reliable triggering non-trivial. |
| Impact | This is a medium-severity, availability-only issue (CVSS 4.8, CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) and the signals are internally consistent rather than conflicting. The attack vector is Adjacent (AV:A), i.e. Bluetooth radio range, not the Internet, and attack complexity is High (AC:H) because success depends on winning an unsynchronized race window between the RX thread and the system workqueue. Privileges Required is Low (PR:L), which the description substantiates concretely: the attacker must be a provisioned mesh member holding the NetKey and a bound AppKey, so this is an insider/compromised-member threat, not an anonymous one. Impact is confined to availability (A:H) - node crash or reset - with the description explicitly stating no confidentiality or integrity impact and no path to memory corruption or code execution. No EPSS score, KEV listing, SSVC decision, or POC was provided in the input; a patch is available from the vendor. Exploitation status: no public exploit identified at time of analysis. Net: a real but lower-priority defense-in-depth fix, not an urgent widespread threat. NOTE: the input Tags 'RCE' and 'Buffer Overflow' directly contradict the description (CWE-362 race condition causing a fixed NULL-pointer write), and should not drive prioritization. |
| Exploit ScenarioDerived | A provisioned mesh node within Bluetooth range - a legitimate member or a compromised one holding the NetKey and a bound AppKey - streams crafted access-layer messages that elicit model responses, exhausting the 40-entry chunk pool to force bt_mesh_delayable_msg_manage() down the purge path and leave busy_ctx empty while the delayable work item is still armed. If the enqueuer then yields at the wrong moment, the system-workqueue handler dereferences a NULL list entry (pending_msg->fired_time += 10), faulting and aborting the workqueue thread or resetting the node. No public exploit identified at time of analysis; exploitation also requires winning a narrow timing race (AC:H). |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 12, 2026
Availability loss in Zephyr RTOS Bluetooth Mesh affects nodes built with the default access-layer delayable message queue, where an unsynchronized race between the host RX thread and the system workqueue lets the handler touch a context slot that has already been purged. The attacker must be a provisioned mesh member - holding the NetKey and a bound AppKey - within Bluetooth radio range, who can control arrival rate, response size and destination address to exhaust the 4-entry context pool and 40-entry chunk pool and force the purge path; the trigger is a narrow, high-complexity race. Winning it produces a read-modify-write through a NULL-based pointer on the system workqueue thread, which on typical targets faults and aborts that thread (stopping all workqueue-driven functionality, including the mesh timing machinery) or resets the node, so impact is availability only - the write value and address are fixed, so there is no memory corruption or code execution path. Scoring is CVSS 3.1 4.8 (AV:A/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H); no public exploit identified at time of analysis, and there is no KEV listing.
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed - the vendor identifies a patch and the correcting commit is 0a6da68955f454edc41e4b916e05c3b974209fe4 (see the advisory https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-4p55-7h77-fhgr), which 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 reaching the queue front while the stack is suspended or reset. Builds should be updated to a Zephyr revision containing that commit rather than a specific version number, since no exact released tag is confirmed in the provided data. If patching cannot be done immediately, the most direct compensating control is to disable CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG (or CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED) so responses are not parked on the shared queue; the trade-off is loss of delayable/queued access-layer sends, which can increase blocking of the host RX thread and change response timing, so it must be validated against latency and stack-size requirements. Because exploitation requires valid mesh credentials, limiting which nodes hold and can bind AppKeys (and rotating them after any suspected compromise) reduces the attacker pool, and restricting access-layer traffic to trusted, tightly scoped models lowers the response volume an attacker can elicit; enabling a hardware watchdog so a node that faults or resets in the system workqueue recovers automatically limits the downtime window, though it does not prevent the fault itself. Note that the 'RCE' and 'Buffer Overflow' tags in the source data do not match the assessed impact, which is availability only, so remediation should be prioritized accordingly rather than as a code-execution emergency.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is a classic race condition (CWE-362) in subsys/bluetooth/mesh/delayable_msg.c, where three intrusive singly linked lists (busy_ctx, free_ctx, free_chunks) and a single k_work_delayable are shared between two cooperative threads with no synchronization: bt_mesh_delayable_msg_manage() on the Bluetooth host RX thread and delayable_msg_handler() on the system workqueue. Both contexts can block while a list is mid-mutation - the enqueuer inside bt_rand(), and both inside bt_mesh_access_send() - so the other context can observe torn state. Two specific defects follow: delayable_msg_handler() consumed the result of sys_slist_get() on busy_ctx without a NULL check, and allocate_delayable_msg_ctx() tested sys_slist_is_empty() before assuming a separate sys_slist_get() would succeed. Because CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED both default to y, every model response to a received mesh message is parked on this queue, making the enqueuer run as a direct consequence of inbound traffic. Exhausting the 40-entry chunk pool drives 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 remains armed; a yield then lets the handler run against the empty list and perform pending_msg->fired_time += 10 through a NULL-based pointer at a fixed low address. Note that the supplied tags include 'RCE' and 'Buffer Overflow' - these are inconsistent with the actual code path and the independent assessment: no attacker-controlled length or index is involved and the write target/value are fixed, so the realistic outcome is a system workqueue abort or node reset (availability), not code execution. The same unsynchronized window also allows one message context to be selected and released by two contexts simultaneously, yielding duplicated transmissions, duplicated send-completion callbacks and crossed chunk ownership. The CPE entry cpe:2.3:a:zephyrproject:zephyr:*:*:*:*:*:*:*:* reflects that the advisory is version-agnostic across the Zephyr project.
Know when Bluetooth gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:A/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Bluetooth-range vector (AV:A); exploitation needs a provisioned member with NetKey plus bound AppKey (PR:L) and must win an unsynchronized race (AC:H); impact is node crash only (A:H, C/I:N).
Primary rating from Vendor (zephyr).
CVSS VectorVendor: zephyr
DescriptionCVE.org
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.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Race conditions occur when multiple concurrent requests exploit the brief time gap between checking a condition and acting upon it (TOCTOU - Time of Check, Time of Use).
Affected Products (CPE)CVE.org
Unauthenticated Bluetooth Low Energy OTA firmware upgrade in the Meatmeet Pro WiFi & Bluetooth Meat Thermometer firmware
CVE-2025-32879 is a security vulnerability (CVSS 8.8) that allows an attacker. Risk factors: public PoC available.
Zephyr's Bluetooth Low Energy connection-response handler fails to verify that a connection request was actually initiat
Heap OOB write in Android Bluetooth driver via incorrect bounds check.
A use-after-free in the Android Bluetooth stack (bluetooth_ccc.cc, function BluetoothCccHandlerCallbackImpl) lets an att
Legacy pairing and secure-connections pairing authentication in Bluetooth BR/EDR Core Specification v5.2 and earlier may
Memory corruption in the Zephyr RTOS LE Audio Broadcast Sink (subsys/bluetooth/audio/bap_broadcast_sink.c) lets an attac
A memory leak combined with a use-after-free in the Linux kernel's Bluetooth HCI connection-setup path can crash the ker
A race condition in the Linux kernel's Bluetooth L2CAP subsystem allows a use-after-free of the hci_conn::l2cap_data poi
Bluetooth authentication bypass in SwitchBot Door Lock Series allows an attacker within BLE range to manipulate the lock
Out-of-bounds read in the Linux kernel Bluetooth subsystem's eir_get_service_data() leaks kernel heap memory into usersp
Use-after-free in the Linux kernel Bluetooth L2CAP stack lets a Bluetooth-adjacent attacker corrupt kernel memory by rac
NVD
CVE.org
EPSS
GitHub
Exploit-DB