CVE-2026-18746 in Zephyr
Summary
by MITRE • 09/29/2026
parse_write_op() in subsys/net/lib/lwm2m/lwm2m_message_handling.c handles inbound CoAP WRITE/CREATE requests that carry a Block1 option. For the first block of a transfer it called init_block_ctx() and then immediately stored the peer-selected block size with block_ctx->ctx.block_size = block_size before inspecting the return code. init_block_ctx() sets the caller's pointer to NULL and returns -ENOMEM when no entry of the static block1_contexts[] pool is free or timed out, so that store dereferences a NULL pointer.
The pool holds CONFIG_LWM2M_NUM_BLOCK1_CONTEXT entries (default 3) and an entry is only reclaimed once its transfer completes, fails, or ages past 30 seconds. A peer that reaches the client's LwM2M socket can therefore start three block-wise writes on three distinct object paths with the CoAP More bit set and leave them incomplete, then send the first block of a fourth write on a new path to reach the unguarded dereference. Reachability is gated only by the connected UDP socket's source-address filter unless CONFIG_LWM2M_DTLS_SUPPORT is enabled — which has no default — so in a NoSec deployment an on-path or address-spoofing attacker needs no credentials; the same sequence is also reachable from a bootstrap or lower-trust server, and can be hit accidentally by a legitimate server running four concurrent block transfers.
The write targets a fixed low address with a value between 0 and 7, so the consequence is a fatal memory fault (BusFault or corrupted low memory leading to a fault) rather than a usable memory-corruption primitive: the device crashes or resets. Confidentiality and integrity are not affected. The fix moves the store below the guard and validates the context pointer itself instead of the return code, so the context is only touched once it is known to be valid.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability resides in the parse_write_op function within the LwM2M message handling subsystem of Zephyr RTOS, specifically affecting inbound CoAP WRITE and CREATE requests that utilize the Block1 option for block-wise transfers. The core technical flaw is a null pointer dereference caused by an incorrect order of operations during context initialization. When processing the first block of a transfer, the code invokes init_block_ctx to allocate or retrieve a slot from a static pool of block contexts. This function returns -ENOMEM if no entries are available due to exhaustion or timeout conditions and simultaneously sets the caller's pointer variable to NULL. However, the implementation immediately proceeds to dereference this potentially null pointer by assigning the peer-selected block size to block_ctx->ctx.block_size before checking the return code from init_block_ctx for errors. This lack of defensive programming allows a malformed sequence of requests to trigger a fatal memory fault when the context pool is exhausted.
The operational impact stems directly from the resource management strategy employed by the LwM2M implementation, which maintains a fixed-size static array of block contexts determined by CONFIG_LWM2M_NUM_BLOCK1_CONTEXT, typically set to three entries by default. These context entries are retained for up to thirty seconds or until a transfer completes or fails intentionally. An attacker can exploit this finite resource limit by initiating multiple incomplete block-wise writes on distinct object paths while setting the CoAP More bit to indicate continuation. By filling all available slots with pending transfers, an attacker creates a denial-of-service condition where subsequent requests cannot allocate new contexts. When a fourth write request arrives under these conditions, init_block_ctx fails and returns NULL, leading directly to the null pointer dereference described above. This results in a fatal exception such as a BusFault or corruption of low memory regions, causing the device to crash or reset rather than allowing for arbitrary code execution or data manipulation.
From an attack surface perspective, reachability is primarily gated by network connectivity and source address filtering on the UDP socket unless DTLS support is enabled via CONFIG_LWM2M_DTLS_SUPPORT, which is not a default configuration in many deployments. In unsecured environments, this vulnerability can be exploited by on-path attackers or those capable of IP spoofing without requiring authentication credentials. Even in secured configurations, the risk persists for bootstrap servers or lower-trust entities that are permitted to interact with the LwM2M endpoint. Furthermore, the issue is not solely malicious; it can also occur accidentally if a legitimate server initiates four concurrent block transfers exceeding the configured limit, highlighting a robustness flaw rather than just a security bypass. The consequence remains strictly availability-focused, as the write targets fixed low memory addresses with small integer values between zero and seven, preventing the use of this bug for privilege escalation or confidentiality breaches.
To mitigate this vulnerability, developers must apply patches that restructure the control flow within parse_write_op to validate context allocation before any dereference occurs. The recommended fix involves moving the assignment of block_size below the error check for init_block_ctx and validating the context pointer itself rather than relying solely on return codes. This ensures that memory is only accessed when a valid, allocated context exists. Additionally, system administrators should consider increasing CONFIG_LWM2M_NUM_BLOCK1_CONTEXT if their use case requires higher concurrency levels to delay resource exhaustion. Enabling DTLS support provides an additional layer of defense by restricting access to authenticated peers, thereby reducing the attack surface for unauthenticated actors who might otherwise trigger this denial-of-service condition through simple network flooding or state manipulation techniques aligned with ATT&CK tactics related to service disruption and resource exhaustion.