CVE-2026-18747: Integer underflow of net_buf length in the MCUmgr serial (SMP over console) transport leads to out-of-bounds read
The MCUmgr SMP-over-console transport decodes a base64 frame, reads a 16-bit packet length from it, verifies a CRC and then unconditionally strips the trailing CRC with rxctxt->nb->len -= 2U; in mcumgrserialprocessfrag() (subsys/mgmt/mcumgr/transport/src/serialutil.c). mcumgrserialextractlen() accepted any declared length, including 0 and 1, and a packet declaring length 0 passes the checksum test for free because crc16itut() over zero bytes returns the zero seed. Since netbuf::len is a uint16t, the subtraction underflows and the buffer is handed to SMP claiming roughly 65 KB of payload while its data area is only CONFIGMCUMGRTRANSPORTNETBUFSIZE bytes (default 384).
The trigger is a single unauthenticated 7-byte line on the management console — the 0x06 0x09 packet marker followed by the base64 group AAA= and a newline — delivered to any transport built on this helper: CONFIGMCUMGRTRANSPORTUART (smpuart.c) or CONFIGMCUMGRTRANSPORTSHELL (smpshell.c), both of which select MCUMGRTRANSPORTSERIALHASSMPOVERCONSOLE. No prior session state, fragmentation or credentials are required to trigger the underflow, and the malformed frame is mishandled before any command handler or command-level access control runs. The attacker only needs write access to that console, which on many boards is a USB CDC-ACM port rather than a bare UART header.
With the inflated length, smpprocessrequestpacket() in subsys/mgmt/mcumgr/smp/src/smp.c loses its bound: cbornbreaderinit() gives the CBOR decoder a ~65 KB window into a 384-byte buffer, and each request header's nhlen is checked only against the inflated length. On its own the 7-byte frame re-parses whatever stale bytes the reused pool buffer still holds, typically a replay of the previously received request followed by a parse error, without leaving the buffer. Because the transport is unauthenticated, though, the attacker also controls the frames sent before the trigger, and can stage buffer contents so that a request succeeds with an nhlen larger than the buffer; netbufpull(), guarded only by ASSERTNOMSG, then moves the parse cursor out of bounds and the loop reads further headers and CBOR from adjacent memory. The consequence is an out-of-bounds read that can fault the MCUmgr thread (denial of service); memory disclosure is also possible, since the default-enabled os echo handler (CONFIGMCUMGRGRPOSECHO) decodes its string inside that window and copies it into its response. There is no integrity gain beyond what the unauthenticated transport already permits.
The fix rejects any declared packet length of two bytes or fewer in mcumgrserialextractlen(), so the CRC-strip subtraction can no longer underflow. The identical pattern remains in the test-only loopback transport subsys/mgmt/mcumgr/transport/src/smpdummy.c (CONFIGMCUMGRTRANSPORTDUMMY), which has no external input path and therefore carries no practical exposure.
Affected Software
Event History
Frequently Asked Questions
Which configurations are exposed?
Systems that enable either CONFIG_MCUMGR_TRANSPORT_UART or CONFIG_MCUMGR_TRANSPORT_SHELL are affected, because both select MCUMGR_TRANSPORT_SERIAL_HAS_SMP_OVER_CONSOLE. The issue is in the shared serial transport helper.
What access does an attacker need?
An attacker needs access to the management console transport to submit a malformed line. No credentials, prior session state, or fragmentation are required, and the malformed frame is processed before command authentication.
Are default buffer settings sufficient to limit the impact?
No. The described default CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE is 384 bytes, but the uint16_t length underflow causes SMP to receive a claimed payload length of roughly 65 KB.
How can I identify potentially affected builds?
Check whether the build enables CONFIG_MCUMGR_TRANSPORT_UART or CONFIG_MCUMGR_TRANSPORT_SHELL. Affected code includes mcumgr_serial_process_frag() and mcumgr_serial_extract_len() in subsys/mgmt/mcumgr/transport/src/serial_util.c.
What source change should be reviewed for remediation?
Review the change identified by commit f7fc3e779a59c68c96eaf63a6b03ac7489f5e4a5, which is referenced with the advisory. No fixed release version is provided in the available data.