Zephyr RTOS Memory Safety and DoS Vulnerabilities

An out-of-bounds read in Zephyr's MCUmgr SMP-over-console transport (subsys/mgmt/mcumgr/transport/src/serial_util.c) lets a single 7-byte, unauthenticated console line underflow a net_buf length field and hand the SMP layer a bogus ~65 KB payload window over a buffer whose data area defaults to 384 bytes. The flaw affects builds that enable CONFIG_MCUMGR_TRANSPORT_UART (smp_uart.c) or CONFIG_MCUMGR_TRANSPORT_SHELL (smp_shell.c), both of which select MCUMGR_TRANSPORT_SERIAL_HAS_SMP_OVER_CONSOLE; the test-only CONFIG_MCUMGR_TRANSPORT_DUMMY loopback carries the same pattern but has no external input path and is not exploitable. Because exploitation needs only write access to the management console - on many boards an exposed USB CDC-ACM port rather than a bare UART header - the practical impact is a faulted MCUmgr thread (denial of service) plus possible limited memory disclosure via the default-enabled os echo handler; no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV).

Repeated network-interface link-down events can crash or reset devices running Zephyr RTOS v4.3.0 that keep a listening TCP socket open, because the BSD-socket layer parks a pending errno value in the net_context user_data field while the TCP core simultaneously expects that field to hold a parent context pointer; a second interface-down event forwards the stale integer to zsock_accepted_cb(), which dereferences it as a pointer and writes through it, producing a wild-pointer access and a kernel fatal error (denial of service, not attacker-directed memory corruption). The flaw is reachable by unauthenticated adjacent attackers who can force the link down repeatedly (CVSS 3.1 AV:A/AC:L/PR:N/UI:N, 6.5, availability-only impact), and no public exploit code or confirmed active exploitation has been identified at time of analysis. Zephyr v4.3.1 and v4.4.x carry a follow-up change that clears the accept callback after the error path, reducing the issue to a narrow handshake-versus-interface-down race plus an unconditional getsockopt(SO_ERROR) read-back of the kernel pointer stored in user_data, so those lines are far less practically exploitable than v4.3.0.

Denial of service in the Zephyr RTOS LwM2M client: the CoAP Block1 write handler can be driven into a NULL pointer dereference that crashes or resets the device. Affected are Zephyr builds using the LwM2M engine with block-wise transfer handling, particularly NoSec deployments where CONFIG_LWM2M_DTLS_SUPPORT is disabled (it has no default, so this is a common configuration); an unauthenticated remote peer that can reach the LwM2M UDP socket - an on-path or address-spoofing attacker, or a bootstrap/lower-trust server - first exhausts the static Block1 context pool (CONFIG_LWM2M_NUM_BLOCK1_CONTEXT, default 3) with three incomplete block-wise writes, then sends a fourth first-block write to hit the unguarded store. The assessed impact is availability only (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, CVSS 5.9), and no public exploit code was identified at time of analysis; the multi-request pool-exhaustion sequence is the main factor keeping complexity high.