Zephyr RTOS CVE-2026-15892

Three Kconfig conditions must ALL be simultaneously true in the firmware build: (1) CONFIG_MCUMGR_GRP_SETTINGS_BUFFER_TYPE_HEAP must be explicitly selected - the default is the stack buffer type, so this requires a deliberate developer choice; (2) CONFIG_MCUMGR_GRP_SETTINGS_ACCESS_HOOK must be enabled, meaning the application registers a callback to control settings access; and (3) the registered access hook must return MGMT_CB_ERROR_RC (not MGMT_CB_ERROR_RSN or success) to reject a request - MGMT_CB_ERROR_RC is a common rejection style but is not the only option. The SMP transport must also be reachable: exploitation over BLE requires the attacker to be within radio range and the device to accept SMP without pairing; over UDP, the device must be network-reachable. UART transport requires physical access. The access hook itself - the mechanism intended to block unauthorized access - paradoxically enables the leak when used with MGMT_CB_ERROR_RC, so the very security control triggers the vulnerability.

The vendor-assigned CVSS 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) overstates the real-world attack complexity because it does not account for the triple configuration prerequisite: heap buffer type, access hook enabled, and a hook that returns MGMT_CB_ERROR_RC specifically. A more accurate assessment would set AC:H, yielding a score closer to 3.7. While EPSS data was not supplied, the niche configuration conditions and embedded-only deployment model suggest a low exploitation probability in practice; even a mid-sized municipal IT team in walbrzych running smart-building IoT infrastructure would need to audit which Zephyr firmware images actually select all three Kconfig options before treating this as urgent. There is no KEV listing and no public exploit, and the impact ceiling is a soft availability denial (gradual heap exhaustion) with no data loss or code execution. The most practically dangerous scenario is a product that intentionally exposes SMP over UDP or BLE to untrusted endpoints and whose firmware developer chose MGMT_CB_ERROR_RC as the hook rejection style - a common but not universal pattern.

An attacker within Bluetooth LE range (or UDP network reach) of a vulnerable Zephyr device sends a rapid stream of SMP settings read commands for arbitrary key names. Each request is rejected by the access hook with MGMT_CB_ERROR_RC, but the key_name and data buffers allocated by k_malloc() are never freed. After hundreds or thousands of requests - depending on the device's heap size - k_malloc() begins failing for the entire system, causing mcumgr operations and any other heap-dependent firmware component to malfunction until the device is power-cycled.