CVE-2026-15892: Heap memory leak in mcumgr settings-management handlers on access-hook rejection leads to denial of service
The mcumgr SMP settings-management group handlers settingsmgmtread(), settingsmgmtwrite(), and settingsmgmtdelete() in subsys/mgmt/mcumgr/grp/settingsmgmt/src/settingsmgmt.c allocate a keyname buffer (and, for read, a data buffer) via kmalloc() when CONFIGMCUMGRGRPSETTINGSBUFFERTYPEHEAP is enabled, relying on the end: label to kfree() them. When CONFIGMCUMGRGRPSETTINGSACCESSHOOK is also enabled and the application access hook rejects a request by returning status MGMTCBERRORRC, the handler executed return retrc; 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 MGMTCBERRORRC 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 kmalloc() 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 MGMTCBERRORRC are affected (the default stack buffer type cannot leak).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Disable CONFIG_MCUMGR_GRP_SETTINGS_BUFFER_TYPE_HEAP so the settings-management handlers do not allocate key_name (and data for read) with k_malloc() in the heap.
mcumgr settings-management (settings_mgmt.c) CONFIG_MCUMGR_GRP_SETTINGS_BUFFER_TYPE_HEAP = disable - Configuration
Disable CONFIG_MCUMGR_GRP_SETTINGS_ACCESS_HOOK to prevent rejected settings access from bypassing the end: label (and therefore prevent heap allocations from leaking).
mcumgr settings-management (access hook) CONFIG_MCUMGR_GRP_SETTINGS_ACCESS_HOOK = disable - Configuration
Update the registered access hook so that when it rejects unauthorized settings access it does NOT return MGMT_CB_ERROR_RC; the leak occurs when the handler returns ret_rc directly on MGMT_CB_ERROR_RC and bypasses k_free().
mcumgr settings-management (application access hook) access hook return value = not MGMT_CB_ERROR_RC
Event History
Frequently Asked Questions
Which deployments are exposed to remote exploitation?
Deployments are exposed when the settings-management group is reachable through an unauthenticated SMP transport configured for the product, such as Bluetooth LE, UART, or UDP. The vulnerable heap-allocation path also requires CONFIG_MCUMGR_GRP_SETTINGS_BUFFER_TYPE_HEAP and CONFIG_MCUMGR_GRP_SETTINGS_ACCESS_HOOK to be enabled.
What must an attacker do to trigger the leak?
An attacker must send settings read, write, or delete requests that the application access hook rejects by returning MGMT_CB_ERROR_RC. No authentication, privileges, or user interaction are required when the affected settings handlers are reachable on an unauthenticated SMP transport.
What happens operationally during an attack?
Each rejected request leaks one or more heap allocations that are not reclaimed until reboot. A sustained stream of rejected requests can exhaust the kernel heap, causing k_malloc() failures and denial of service.
How can an affected system be recognized during or after exploitation?
The expected symptom is monotonically increasing heap exhaustion following rejected settings-management requests, eventually resulting in k_malloc() failures. The leaked memory is only recovered by rebooting.