Zephyr RTOS CVE-2026-19937

Requires an attacker already provisioned into the target mesh network, holding a valid NetKey plus an AppKey or DevKey bound to a server model, and within Bluetooth radio range of the victim (AV:A). The target must be built with CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED, both enabled by default, so default configurations are vulnerable. The attacker must simultaneously drive two runtime conditions: keep all segmented-TX contexts occupied (by flooding requests that elicit segmented responses while withholding Segment Acknowledgments) and keep the chunk pool (CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CHUNK_COUNT, default 40) short, so each further request hits the error path and leaks one of the four default contexts. Limiting factors: the Bluetooth-adjacent position, the requirement to be a trusted/provisioned mesh participant (not anonymous), and the need to maintain the TX-busy + chunk-starvation window; pre-fix releases that size chunks from buffer capacity rather than payload length make the starvation easier to provoke.

This is a medium-severity, availability-only defect (CWE-772, missing resource release) and the signals are internally consistent rather than conflicting. The provided CVSS 3.1 vector (AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 5.7) correctly caps impact at availability - the description explicitly rules out memory corruption, information disclosure, and integrity impact, so the 'Buffer Overflow' and 'Information Disclosure' tags in the input are wrong and should be disregarded. Two factors meaningfully constrain real-world risk: AV:A means the attacker must be within Bluetooth radio range (not internet-reachable), and PR:L means the attacker must already be provisioned into the target mesh network holding a valid NetKey plus an AppKey or DevKey bound to a server model - i.e. an insider/compromised-node position, not an anonymous remote attacker. No EPSS score, CISA KEV listing, or public POC was supplied, so there is no evidence of active exploitation; per precision rules this is 'no public exploit identified at time of analysis.' The one amplifying factor is that the required pre-conditions (CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED) are enabled by default, and the resource leak is permanent across unprovision/re-provision/suspend/resume until reboot, making the DoS sticky. Net: a genuine but moderate-priority issue for operators of default-configured Zephyr Bluetooth Mesh nodes who cannot fully trust every provisioned peer; prioritize patching, but it is not a widespread remote-exploitation emergency.

A node already provisioned into the mesh (e.g. a compromised or malicious peer with a valid NetKey and a bound AppKey/DevKey) floods a victim node with requests that elicit segmented responses while deliberately withholding Segment Acknowledgments, pinning all transmit contexts busy while queued responses hold the chunk pool. Each additional request that hits the chunk-exhaustion error path in bt_mesh_delayable_msg_manage() permanently leaks one of the four static message contexts; once the pool is drained the node silently drops all Configuration/Health/application server replies until it is rebooted. No public exploit code was identified at time of analysis, and because AV:A applies the attacker must be within Bluetooth range.