u-boot.git/boot, branch main

Merge patch series "vbe: bound FIT external-data reads against the firmware area"

2026-07-16T18:06:40Z

Aristo Chen says: vbe_read_fit() loads a firmware-phase FIT from a fixed firmware area on a block device and then issues a follow-up blk_read() to pull in the image, and optionally an FDT, referenced by the FIT's image node. The source offset on the device and the read length both come from the FIT itself, via data-position or data-offset and data-size. Those properties live on mutable boot media and can be controlled by an attacker with write access to the firmware area. On the TPL or VPL path, and on the bootmeth bootflow path reached via abrec_read_bootflow_fw() and vbe_simple_read_bootflow_fw(), the follow-up blk_read() runs before any signature or hash check on the loaded phase. Patch 1 is a sandbox test-tree preparation. The firmware1 node in arch/sandbox/dts/test.dts declared area-size = 0xe00000 (14 MiB), but the binman fw-update section in sandbox_vpl.dtsi is 32 MiB and the FIT inside it carries ~16 MiB of external data, so the FIT already extended past the declared area. The mismatch was tolerated because no caller bounded the external-data load against area_size. Patch 1 raises area-size to match the binman section size so test_vbe_vpl keeps passing once the bound is enforced. The patches are ordered so the test is never broken in the middle of the series. Patch 2 adds the missing range check, confining the FIT-supplied [load_addr, load_addr + len) window to [addr, addr + area_size] before block numbers and lengths are computed, and applying the same constraint to fdt_load_addr and fdt_size. The check is written in subtraction-only form against the trusted area_size so the comparison cannot itself overflow. Patch 3 adds two sandbox unit tests under test/boot/ that construct synthetic FITs with out-of-range data-position and oversized data-size, write them to mmc1, and confirm vbe_read_fit() returns -E2BIG for each before issuing the follow-up blk_read(). Deferring the external-data blk_read() until after the phase has been signature-verified would be a stronger structural fix and was discussed on the v1 thread. Simon confirmed the bounded read is the right first step and that the verify-then-load change should be a separate series, so this v3 stays scoped to the bound. Link: https://lore.kernel.org/r/20260705034414.2247-1-aristo.chen@canonical.com

vbe: bound FIT external-data offset and size before blk_read

2026-07-16T18:06:15Z

vbe_read_fit() loads a firmware-phase FIT from the trusted firmware area and then issues a blk_read() to pull in the image, and optionally an FDT, referenced by the FIT image node. The source offset on the device and the read length both come from the FIT's data-position or data-offset property and its data-size property, which live on mutable boot media and can be controlled by an attacker with prior write access to the firmware area. Without a range check the resulting blk_read() can read past the firmware area on the device and, on the non-SPL path, write an attacker-chosen number of blocks past the malloc(aligned_size) FIT buffer into adjacent memory. Only the SPL branch routes through spl_load_simple_fit(), which hashes the data. The external-data block reached from TPL or VPL, and from the bootflow path via abrec_read_bootflow_fw() and vbe_simple_read_bootflow_fw(), runs before any signature or hash check on the loaded phase. Confine the FIT-supplied [load_addr, load_addr + len) window to [addr, addr + area_size] before computing block numbers and lengths, and apply the same constraint to fdt_load_addr and fdt_size. The checks are written in subtraction-only form against the trusted area_size so the comparison itself cannot overflow. Reviewed-by: Simon Glass Signed-off-by: Aristo Chen

cmd: fdt: keep control FDT during checksign

2026-07-13T23:06:29Z

The fdt checksign command accepts an optional address for an FDT containing public keys. It currently installs that blob as gd->fdt_blob before verifying the FIT configuration. This breaks verification with DM-backed crypto drivers which have not probed yet, since the later probe path expects gd->fdt_blob to remain U-Boot's control FDT. For example, an ECDSA verifier can be bound from the control FDT but fail to probe after fdt checksign points gd->fdt_blob at the key-only DTB. Add a FIT config verification helper that takes the key blob explicitly and use it from fdt checksign. This keeps gd->fdt_blob unchanged while still allowing the command to verify against an external key DTB. Signed-off-by: James Hilliard

bootdev: scan boot devices at each priority level

2026-07-03T16:14:25Z

Currently, default 'bootflow scan -lb' will stop booting the board if any of higher-priority bootdevs fail to be hunted even if there are bootdevs of lower priority. For example, if the board has both NVMe (priority 4) and USB MSD devices (priority 5), and if NVMe bootdev hunt fails (in the event of a bad NVMe firmware update), USB (which may be a recovery bootdev) is never hunted automatically, leaving the board at the U-Boot prompt (user intervention is needed, e.g. something like 'bootflow scan usb' to hunt USB). Fix bootdev_next_prio() to scan bootdevs at the lower priority level by not exiting the scan loop early. Keep the existing logging verbosity unchanged and rely on the failing subsystem to provide a suitable diagnostic message. Signed-off-by: Denis Mukhin Reviewed-by: Simon Glass

Merge patch series "bootm: fix flush_cache() with IH_TYPE_KERNEL_NOLOAD"

2026-07-03T16:13:14Z

This patch series from Nora Schiffer addresses a few issues with correctly handling IH_TYPE_KERNEL_NOLOAD in a few cases. Link: https://lore.kernel.org/r/20260622111933.1488593-1-nora.schiffer@ew.tq-group.com

bootm: allow omitting entry point for IH_TYPE_KERNEL_NOLOAD

2026-07-03T16:11:11Z

For IH_TYPE_KERNEL_NOLOAD, the entry point is given relative to the image start, making 0 a valid default, and for IH_OS_EFI, it is ignored altogether, so it may be preferable to omit it. Signed-off-by: Nora Schiffer Reviewed-by: Simon Glass

bootm: warn about load address for IH_TYPE_KERNEL_NOLOAD in FIT

2026-07-03T16:11:11Z

The load address is ignored for IH_TYPE_KERNEL_NOLOAD. Instead of failing the boot when none is set, it makes more sense to warn when it *is* set. Signed-off-by: Nora Schiffer Reviewed-by: Simon Glass

bootm: fix flush_cache() with IH_TYPE_KERNEL_NOLOAD

2026-07-03T16:11:11Z

`flush_start` must be set after `load` has been assigned. Fixes: 69544c4fd8b1 ("bootm: Support kernel_noload with compression") Signed-off-by: Nora Schiffer Reviewed-by: Simon Glass

bootm: move OS index bound check into the legacy path

2026-07-01T18:42:23Z

Commit 103b1e7ce8cc ("bootm: bound-check OS index in bootm_os_get_boot_func()") added a range check to the shared accessor so an out-of-range OS id can no longer drive an out-of-bounds read of boot_os[]. That accessor is reached by every image format, but only a legacy uImage can deliver an unchecked value. bootm_find_os() takes the raw 8-bit ih_os byte straight from image_get_os() for legacy images, whereas the FIT path reaches the accessor only after fit_image_load() has rejected any image whose os is not one of the supported types, and the Android path hardcodes IH_OS_LINUX. The check can therefore never fail for FIT, where it only adds confusion and code. Move the test to the legacy branch of bootm_find_os(), rejecting an out-of-range OS where the untrusted byte enters. This keeps the FIT path clear and lets the check be compiled out when CONFIG_LEGACY_IMAGE_FORMAT is disabled. A valid OS id that has no handler is still reported by the existing NULL return path in bootm_run_states(). Suggested-by: Simon Glass Signed-off-by: Aristo Chen Reviewed-by: Simon Glass

Kconfig: boot: restyle

2026-06-25T20:13:31Z

Restyle all Kconfigs for "boot": Menu entries : no space left Menu attributes: 1 TAB Help text : 1 TAB + 2 spaces Replace '---help---' by 'help' Signed-off-by: Johan Jonker