CVE-2026-15892 in Zephyr
Summary
by MITRE • 09/14/2026
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).
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified in the mcumgr settings-management group handlers represents a critical resource management flaw within the Zephyr RTOS subsystem. Specifically, the functions settings_mgmt_read(), settings_mgmt_write(), and settings_mgmt_delete() contain an improper cleanup mechanism that leads to memory leaks under specific configuration conditions. When the system is configured with CONFIG_MCUMGR_GRP_SETTINGS_BUFFER_TYPE_HEAP enabled, these handlers allocate a key_name buffer via k_malloc for write and delete operations, or both a key_name and data buffer for read operations. The intended design relies on a centralized end label within the function scope to ensure that all dynamically allocated memory is freed using k_free before the function returns control to the caller. This standard pattern ensures proper resource lifecycle management in C-based embedded systems where manual memory management is required.
The core technical flaw arises when CONFIG_MCUMGR_GRP_SETTINGS_ACCESS_HOOK is enabled and an application-defined access hook rejects a request by returning MGMT_CB_ERROR_RC. In this specific error path, the handler executes return ret_rc directly instead of jumping to the end label responsible for freeing the allocated buffers. This control flow bypass effectively skips the cleanup routine, leaving the heap-allocated memory blocks orphaned in the kernel heap space. Since the pointers to these allocations are lost and not stored globally or passed back to a higher-level manager that might attempt recovery, the operating system cannot reclaim this memory until the device is rebooted. Consequently, every rejected request results in a permanent loss of heap capacity equal to the size of the allocated buffers.
From an operational perspective, this vulnerability creates a straightforward denial-of-service vector against devices utilizing unauthenticated SMP transports such as Bluetooth Low Energy, UART, or UDP, depending on the product configuration. The mcumgr protocol is often exposed for device management and debugging purposes, making it accessible to potential attackers who can interact with the interface without prior authentication. An attacker can exploit this flaw by sending a sustained stream of settings read, write, or delete commands that are designed to be rejected by the application's access hook logic. Because MGMT_CB_ERROR_RC is a common rejection status code used in many legitimate security policies, triggering it does not require sophisticated evasion techniques; any request violating the configured policy will trigger the leak.
The impact of this vulnerability is strictly availability-related due to the monotonic exhaustion of kernel heap space. As rejected requests accumulate, the available memory for other system components diminishes until k_malloc() begins to fail across the entire operating system. This failure can cause crashes in unrelated services, halt device functionality, or render the mcumgr service itself unusable because it cannot allocate new buffers for subsequent operations. It is important to note that this vulnerability does not lead to memory corruption, arbitrary code execution, or information disclosure of sensitive data contained within the leaked buffers, as those buffers are typically cleared or used only transiently before being lost. The attack surface is limited to configurations where heap-based buffering is explicitly selected alongside an enabled access hook that returns error codes for unauthorized requests.
To mitigate this vulnerability, developers must ensure that all code paths in settings_mgmt_read(), settings_mgmt_write(), and settings_mgmt_delete() lead to the proper cleanup routine regardless of early return conditions caused by security hooks. The most direct fix involves refactoring these functions so that the end label is reached via goto statements or restructuring the control flow to guarantee k_free calls are executed before any return statement associated with an error code from the access hook. Alternatively, if heap allocation for settings buffers introduces unacceptable risk in unauthenticated contexts, organizations should consider disabling CONFIG_MCUMGR_GRP_SETTINGS_BUFFER_TYPE_HEAP and relying on stack-based buffering where feasible, although this may impose limits on buffer sizes. Additionally, implementing strict rate limiting or authentication requirements for SMP transports can reduce the exposure window by preventing unauthorized entities from sending high volumes of requests that trigger the leak condition.
This vulnerability aligns with CWE-401, which describes a missing release of memory after effective usage, and falls under MITRE ATT&CK technique T1499, Endpoint Denial of Service, specifically through resource exhaustion via application-level flaws rather than network flooding alone. The lack of proper resource deallocation in response to security policy enforcement actions highlights a common oversight in embedded systems development where error handling paths are not as rigorously tested for side effects like memory leaks as the success paths. Addressing this requires a comprehensive review of all mcumgr handlers that perform dynamic allocation to ensure consistent adherence to RAII-like principles or explicit cleanup guarantees across all exit points within the function scope.