CVE-2026-10648: Zephyr MCUmgr Serial Null-Pointer Dereference DoS Vulnerability

Technical summary

The vulnerability resides in mcumgr_serial_process_frag() within serial_util.c. The function calls net_buf_reset() on the return value of smp_packet_alloc() before validating that the allocation succeeded. Since smp_packet_alloc() uses net_buf_alloc(K_NO_WAIT) against a finite shared pool (CONFIG_MCUMGR_TRANSPORT_NETBUF_COUNT, default 4 buffers), it returns NULL when the pool is exhausted. In default Zephyr builds, the assertion macro in net_buf_reset() is a no-op, so execution proceeds to net_buf_simple_reset(), which unconditionally writes to the null pointer (buf->len = 0; buf->data = buf->__buf), triggering a fault. Fragment data originates from untrusted MCUmgr serial/UART/shell-console transports, and a fresh buffer allocation is requested at the start of nearly every incoming packet, making pool exhaustion trivial for a local attacker.

Business impact

Affected Zephyr deployments—particularly IoT devices, embedded systems, and firmware that expose MCUmgr serial interfaces—face immediate denial-of-service risk. An attacker with physical or logical access to the serial port can repeatedly crash the device with minimal effort, disrupting availability and potentially triggering expensive field recalls or device lockouts. For safety-critical or always-on systems, even brief unavailability can cascade into broader operational failures.

Affected systems

Zephyr v4.4.0 and later versions are affected, as the vulnerable code was introduced after the MCUmgr transport rework. Any Zephyr-based embedded system or IoT device that (1) runs Zephyr v4.4.0 or later, (2) has MCUmgr enabled, and (3) exposes at least one serial/UART or shell-console transport interface is vulnerable. The default packet pool size of 4 makes exploitation easy; custom configurations with larger pools reduce but do not eliminate risk.

Exploitability

Exploitation requires only local access to an enabled serial/UART or shell-console transport—no remote capability, authentication, or user interaction. An attacker can craft a simple sequence of MCUmgr packet fragments designed to allocate buffers faster than they are released, filling the pool and triggering the crash. Proof-of-concept tooling for MCUmgr protocol manipulation already exists in the security community. The attack is deterministic and highly reliable once the pool is saturated.

Remediation

Upgrade to a patched Zephyr release that moves the NULL pointer check before the net_buf_reset() call. The fix is minimal and surgical: validate smp_packet_alloc() return value and handle allocation failure gracefully (typically by discarding the fragment or returning an error) before dereferencing the buffer. Verify the specific patched version against the official Zephyr project advisory and release notes. In the interim, disable MCUmgr serial transports if not operationally required, or restrict physical/logical access to serial interfaces.

Patch guidance

Apply the official Zephyr patch that reorders the NULL check before net_buf_reset(). Verify against the Zephyr project's official security advisory and commit history. Update to the earliest available Zephyr release that includes the fix. Organizations should test the patch in a non-production environment first to ensure compatibility with customized MCUmgr configurations or board-specific serial handling.

Detection guidance

Monitor device logs and crash dumps for null-pointer dereference faults originating from serial_util.c or the MCUmgr transport layer. Inspect serial port traffic for patterns of rapid MCUmgr packet fragments arriving in bursts—indicative of deliberate pool-exhaustion attempts. Implement rate-limiting or connection throttling on serial interfaces if operationally feasible. For development and testing, enable kernel assertions (__ASSERT_NO_MSG) to catch the null dereference earlier in the development cycle.

Why prioritize this

Despite a CVSS score of 6.2 (Medium), this vulnerability merits prompt attention in many embedded deployments. The attack vector is local and unauthenticated, the exploitability is trivial, and the impact (complete device crash) is total within the scope of the process. Organizations with exposed serial interfaces on production or field-deployed Zephyr devices should prioritize patching. The risk is lower for devices with restricted physical access or serial console isolation.

Risk score, explained

CVSS 3.1 assigns a score of 6.2 (Medium severity). Attack Vector is Local (L) because the serial/UART interface must be physically or logically accessible; Attack Complexity is Low (L) because no special conditions are required; Privileges Required and User Interaction are None (N); Scope is Unchanged (U); and the impact is limited to Availability (A:H) with no Confidentiality or Integrity loss. The Medium rating reflects the local-only vector; however, in embedded and IoT contexts where serial consoles are often readily accessible, operational risk may be higher than the numeric score suggests.

Frequently asked questions