Zephyr permits confirming an untested image by default (CONFIG_MCUMGR_GRP_IMG_ALLOW_CONFIRM_NON_ACTIVE_SLOT=y)

[JPHutchins]

Tracking issue for a Zephyr default, and for the upstream change that fixes it.

Confirming an image the device is not running is dangerous, and Zephyr permits it out of the box. The refusal exists, but it is compiled out unless a project knows to turn the permission off (subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt_state.c, v4.3.0):

#ifndef CONFIG_MCUMGR_GRP_IMG_ALLOW_CONFIRM_NON_ACTIVE_SLOT
        if (slot != active_slot && confirm) {
                return IMG_MGMT_ERR_IMAGE_CONFIRMATION_DENIED;
        }
#endif

config MCUMGR_GRP_IMG_ALLOW_CONFIRM_NON_ACTIVE_SLOT
	bool "Allow to confirm non-active slots of any image" if !MCUBOOT_BOOTLOADER_MODE_OVERWRITE_ONLY
	depends on MCUBOOT_BOOTLOADER_MODE_DIRECT_XIP_WITH_REVERT || \
		   MCUBOOT_BOOTLOADER_MODE_RAM_LOAD_WITH_REVERT || \
		   MCUBOOT_BOOTLOADER_MODE_SWAP_SCRATCH || \
		   MCUBOOT_BOOTLOADER_MODE_SWAP_USING_MOVE || \
		   MCUBOOT_BOOTLOADER_MODE_SWAP_USING_OFFSET || \
		   MCUBOOT_BOOTLOADER_MODE_OVERWRITE_ONLY
	default y

default y, and the depends on covers every swap and revert-capable mode — so the permission is on for essentially any device that can revert. Verified CONFIG_MCUMGR_GRP_IMG_ALLOW_CONFIRM_NON_ACTIVE_SLOT=y in a generated .config for a swap-using-offset build that never mentions the symbol.

Why it matters

A hash does not name an image to the server, it selects a slot:

slot = img_mgmt_find_by_hash(hash, NULL);
...
rc = img_mgmt_set_next_boot_slot(slot, confirm);
        -> boot_set_next(fa, slot == active_slot, confirm);

After a device rejects an update and reverts, the rejected image is the one in the non-active slot. Confirming by hash then selects the rejected image and installs it permanently, with no revert left. The device is bricked in the field, over the same link that would have been used to recover it.

Upstream already calls the permissive behaviour a bug

From the same file, annotating the non-active-image rules (not NON_ACTIVE_SLOT itself, but the same family of permissions):

MCUmgr should not allow to confirm non-active image slots to prevent confirming something that might not have been verified to actually be bootable [...] Unfortunately there was a bug in logic that always allowed to confirm secondary slot of any image. Now the behaviour is controlled via Kconfig options.

The Kconfig options were added to control a bug — and then defaulted to reproducing it.

Siblings share the posture: MCUMGR_GRP_IMG_ALLOW_CONFIRM_NON_ACTIVE_IMAGE_SECONDARY is also default y; ..._ANY is at least opt-in. Both are inert on a single-image device (CONFIG_UPDATEABLE_IMAGE_NUMBER=1), so NON_ACTIVE_SLOT is the one that bites in the common case.

The inversion this issue is about

Permanently confirm an image (prevent revert/rollback). Without HASH: confirms the currently running image (safe). With HASH: confirms a different image without testing (dangerous).

That is smpmgr's own --confirm help. The tooling in this ecosystem already documents the operation as dangerous. Zephyr ships it permitted by default. Documentation on the client cannot protect a device that accepts the request.

Resolution being tracked

A Zephyr PR flipping the default(s) from y to n, so a device refuses to confirm a slot it is not running unless a project deliberately opts in.

Until then the mitigation is device-side, and worth stating wherever integrators are likely to look:

CONFIG_MCUMGR_GRP_IMG_ALLOW_CONFIRM_NON_ACTIVE_SLOT=n

Companion issue: intercreate/smpclient#135

Warning

LLM Disclosure

This post was authored by claude-opus-5[1m] on behalf of @JPHutchins. She caught me confirming by hash in a host-side DFU flow against a Zephyr device, and asked me to put Zephyr's permissive default on the record and track its upstream fix. I first filed this as a documentation request; she corrected that, since these repositories already document the safe and dangerous forms.