Description

The mcumgr SMP settings-management group handlers settings_mgmt_read(), settings_mgmt_write(), and settings_mgmt_delete() in subsys/mgmt/mcumgr/grp/settings_mgmt/src/settings_mgmt.c allocate a key_name buffer (and, for read, a data buffer) via k_malloc() when CONFIG_MCUMGR_GRP_SETTINGS_BUFFER_TYPE_HEAP is enabled, relying on the end: label to k_free() them. When CONFIG_MCUMGR_GRP_SETTINGS_ACCESS_HOOK is also enabled and the application access hook rejects a request by returning status MGMT_CB_ERROR_RC, the handler executed return ret_rc; directly, bypassing end: and leaking the heap allocation on every rejected request. The settings handlers are reachable over the unauthenticated SMP transport (Bluetooth LE, UART, or UDP, depending on product configuration). The access hook is the mechanism applications use to deny unauthorized settings access, and MGMT_CB_ERROR_RC is a common rejection style, so an attacker who can send settings read/write/delete commands that the hook rejects triggers a heap leak on each attempt. Because the leaked memory is never reclaimed until reboot, a sustained stream of rejected requests monotonically exhausts the kernel heap until k_malloc() fails, denying mcumgr service and impacting any other heap consumer on the device — a denial of service. The impact is availability-only; there is no memory corruption or information disclosure. Only configurations that select the heap buffer type, enable the access hook, and register a hook that returns MGMT_CB_ERROR_RC are affected (the default stack buffer type cannot leak).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-13T23:16:28.023Z",
  "pubdate": "2026-09-13T23:16:28.023Z",
  "executiveSummary": "A heap memory exhaustion vulnerability exists within the mcumgr settings-management group handlers (settings_mgmt_read(), settings_mgmt_write(), and settings_mgmt_delete()) in subsys/mgmt/mcumgr/grp/settings_mgmt/src/settings_mgmt.c. The vulnerability is triggered when CONFIG_MCUMGR_GRP_SETTINGS_BUFFER_TYPE_HEAP and CONFIG_MCUMGR_GRP_SETTINGS_ACCESS_HOOK are simultaneously enabled.\nWhen an application-defined access hook rejects an SMP request by returning MGMT_CB_ERROR_RC, the handler fails to reach the cleanup routine, resulting in a persistent memory leak. Because these handlers are reachable via unauthenticated transports such as Bluetooth LE, UART, or UDP, an attacker can intentionally flood the device with unauthorized requests to trigger repeated heap allocations that are never reclaimed.\nThis leads to monotonic exhaustion of the kernel heap, culminating in a Denial of Service (DoS) condition where mcumgr service and other heap-dependent system processes fail. The vulnerability specifically affects systems relying on dynamic heap allocation for settings buffers, and does not involve memory corruption or information disclosure, limiting the impact to system availability.",
  "technicalDetails": "The root cause of this vulnerability is an improper error handling path in the mcumgr settings management subsystem. In the affected functions—settings_mgmt_read(), settings_mgmt_write(), and settings_mgmt_delete()—the system performs dynamic memory allocation via k_malloc() to handle input buffers when configured with CONFIG_MCUMGR_GRP_SETTINGS_BUFFER_TYPE_HEAP. Proper resource management is designed to occur at the end: label, which invokes k_free() to release allocated memory before the function returns.\nThe vulnerability is exposed when CONFIG_MCUMGR_GRP_SETTINGS_ACCESS_HOOK is enabled. The access control logic is invoked before the primary processing logic; if the hook returns MGMT_CB_ERROR_RC to deny access, the code path executes a direct 'return ret_rc;' statement. This branch bypasses the cleanup logic located at the 'end:' label, leaving the heap-allocated buffers orphaned.\nAn attacker can exploit this by continuously sending SMP settings management commands to the device over any supported transport (e.g., Bluetooth LE, UART, or UDP). Since these transports are often unauthenticated, the attacker does not require prior credentials to interact with the handlers. By repeatedly triggering the access hook's rejection logic, the attacker induces a controlled heap leak. Because Zephyr's k_malloc() allocations are persistent until explicitly freed or until the system reboots, the heap reaches its capacity threshold over a sequence of rejected requests.\nThe attack flow is as follows: 1) The attacker initiates an SMP request (Read, Write, or Delete) to the settings management group. 2) The system triggers the application-level access hook. 3) The access hook evaluates the request and returns MGMT_CB_ERROR_RC to reject the attempt. 4) The settings handler performs an early return, skipping the k_free() cleanup routine. 5) The allocated memory remains in the heap. 6) The attacker repeats these steps until the kernel heap is exhausted. 7) Subsequent k_malloc() calls fail, causing a crash or service failure for any component requiring heap memory, resulting in a system-wide Denial of Service."
}