Description

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 rx_ctxt->nb->len -= 2U; in mcumgr_serial_process_frag() (subsys/mgmt/mcumgr/transport/src/serial_util.c). mcumgr_serial_extract_len() accepted any declared length, including 0 and 1, and a packet declaring length 0 passes the checksum test for free because crc16_itu_t() over zero bytes returns the zero seed. Since net_buf::len is a uint16_t, the subtraction underflows and the buffer is handed to SMP claiming roughly 65 KB of payload while its data area is only CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE 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: 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. 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, smp_process_request_packet() in subsys/mgmt/mcumgr/smp/src/smp.c loses its bound: cbor_nb_reader_init() gives the CBOR decoder a ~65 KB window into a 384-byte buffer, and each request header's nh_len 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 nh_len larger than the buffer; net_buf_pull(), guarded only by __ASSERT_NO_MSG, 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 (CONFIG_MCUMGR_GRP_OS_ECHO) 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 mcumgr_serial_extract_len(), so the CRC-strip subtraction can no longer underflow. The identical pattern remains in the test-only loopback transport subsys/mgmt/mcumgr/transport/src/smp_dummy.c (CONFIG_MCUMGR_TRANSPORT_DUMMY), which has no external input path and therefore carries no practical exposure.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.8",
  "pubDate": "2026-09-29T00:17:04.473Z",
  "pubdate": "2026-09-29T00:17:04.473Z",
  "executiveSummary": "A critical integer underflow vulnerability exists in the MCUmgr SMP-over-console transport, specifically within the serial frame decoding logic. The vulnerability resides in subsys/mgmt/mcumgr/transport/src/serial_util.c, where the system fails to validate the packet length before performing a length reduction operation to account for the CRC.\nBy submitting a specially crafted frame with a declared length of 0, an attacker triggers a 16-bit integer underflow during the calculation: rx_ctxt->nb->len -= 2U. This results in the net_buf length wrapping to 65,535 bytes, drastically exceeding the actual allocated buffer size defined by CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE (default 384 bytes).\nThe vulnerability allows an unauthenticated attacker with access to the management console (e.g., USB CDC-ACM) to perform out-of-bounds reads, potentially leading to a denial-of-service via thread faulting or unauthorized memory disclosure. Since the transport is unauthenticated, the attacker can stage the heap contents by sending prior frames, effectively allowing them to manipulate the data parsed after the underflow. This bypasses inherent security controls as the exploitation occurs prior to command-level access verification.",
  "technicalDetails": "The vulnerability originates in mcumgr_serial_extract_len() and mcumgr_serial_process_frag() within the MCUmgr serial transport component. The root cause is the lack of bounds checking on the 16-bit packet length decoded from the incoming base64 frame. Specifically, the system accepts lengths of 0 or 1, which bypasses the CRC integrity check since crc16_itu_t() returns the zero seed for empty inputs.\nWhen a packet specifies a length of 0, the operation rx_ctxt->nb->len -= 2U causes the uint16_t length field of the net_buf structure to underflow to 0xFFFF (65,535). This buffer, despite having a physical capacity of only 384 bytes, is subsequently passed to smp_process_request_packet() for CBOR decoding. The cbor_nb_reader_init() function initializes the decoder with this inflated window, causing the CBOR decoder to interpret adjacent memory as part of the packet payload.\nExploitation is trivial for an attacker with write access to the console port. A 7-byte trigger sequence—the 0x06 0x09 packet marker followed by the base64 encoded 'AAA='—is sufficient to induce the underflow. Because the transport does not require authentication, the attacker can influence the buffer contents prior to sending the trigger. By 'priming' the memory with specific byte patterns, the attacker can influence the decoder to process chosen sequences stored in reused pool memory.\nThe attack flow proceeds as follows: 1) The attacker transmits a series of frames to populate the buffer pool with attacker-controlled data; 2) The attacker sends the 7-byte 'AAA=' malicious frame to trigger the integer underflow; 3) The MCUmgr transport logic, deceived by the inflated length, instructs the CBOR decoder to read beyond the legitimate buffer boundary; 4) The decoder parses the stale memory contents. If the attacker targets the os echo handler (CONFIG_MCUMGR_GRP_OS_ECHO), the system may copy these out-of-bounds contents into a response, leading to memory disclosure. Alternatively, the invalid memory access during the parsing loop typically results in a thread fault, causing a denial of service.\nThis issue affects implementations using CONFIG_MCUMGR_TRANSPORT_UART or CONFIG_MCUMGR_TRANSPORT_SHELL, which include the vulnerable serial processing logic."
}