GHSA-j64f-h3ww-f32c: NULL-pointer dereference in MCUmgr serial/console SMP transport on buffer-pool exhaustion

Published Jun 29, 2026

Updated

mcumgrserialprocessfrag() in subsys/mgmt/mcumgr/transport/src/serialutil.c calls netbufreset() on the result of smppacketalloc() before checking it for NULL. smppacketalloc() uses netbufalloc(KNOWAIT) against the shared MCUmgr packet pool (CONFIGMCUMGRTRANSPORTNETBUFCOUNT, default 4), which returns NULL when the pool is exhausted. In default builds the ASSERTNOMSG in netbufreset is a no-op, so netbufsimplereset writes through the NULL pointer (buf->len = 0; buf->data = buf->buf), causing a fault/crash.

The fragment data reaches this code from attacker-controlled bytes on the MCUmgr serial/UART/shell-console transports (smpuart.c, smprawuart.c, smpshell.c), and a fresh buffer is allocated at the start of essentially every new packet. An attacker on the serial/console link can flood the transport to drive the 4-entry buffer pool to exhaustion and induce the NULL dereference, crashing the device (denial of service).

The defect was introduced after the original MCUmgr rework and shipped in Zephyr v4.4.0. The fix moves the NULL check ahead of netbufreset.

Affected Software

1 affected component

Zephyr Zephyr=4.4.0

Event History

Jun 29, 2026

CVE Published

via OSV·10:51 PM

Data Sourced

via OSV·10:51 PM

DescriptionSeverityWeakness

Frequently Asked Questions

Which deployments are exposed to this denial-of-service issue?

Devices using the MCUmgr serial, UART, raw UART, or shell-console SMP transports are exposed when an attacker can send data over the relevant serial or console link. The issue affects builds using the shared MCUmgr packet pool; its default size is four buffers.

What access does an attacker need to trigger the crash?

An attacker needs access to the MCUmgr serial or console transport link and can trigger the issue by flooding it with attacker-controlled fragment data. No privileges or user interaction are required.

Are default configurations affected?

Yes. In default builds, the assertion in net_buf_reset() does not prevent execution after allocation returns NULL, allowing the NULL pointer write and resulting device fault.

How can I determine whether a device is vulnerable?

Check whether the device runs Zephyr v4.4.0 or a build containing the affected mcumgr_serial_process_frag() logic, and whether MCUmgr serial, UART, raw UART, or shell-console transports are enabled. A vulnerable implementation calls net_buf_reset() on the smp_packet_alloc() result before checking it for NULL.

What mitigation is available if the fix cannot be applied immediately?

Restrict or disable access to MCUmgr serial and console transports where possible, especially for untrusted physical or console-connected users. This reduces an attacker's ability to flood the packet pool and trigger the crash.

GHSA-j64f-h3ww-f32c: NULL-pointer dereference in MCUmgr serial/console SMP transport on buffer-pool exhaustion

Affected Software

Event History

Frequently Asked Questions

Which deployments are exposed to this denial-of-service issue?

What access does an attacker need to trigger the crash?

Are default configurations affected?

How can I determine whether a device is vulnerable?

What mitigation is available if the fix cannot be applied immediately?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are exposed to this denial-of-service issue?

What access does an attacker need to trigger the crash?

Are default configurations affected?

How can I determine whether a device is vulnerable?

What mitigation is available if the fix cannot be applied immediately?