u-boot.git/test/boot, branch next

bootstd: Free abandoned bootflows while scanning

2026-08-21T23:20:57Z

bootflow_scan_first()/bootflow_scan_next() try each candidate (bootdev, method, partition) in turn. When a candidate fails and is not returned to the caller (no BOOTFLOWIF_ALL), the bootflow is simply abandoned: the next candidate's bootflow_init() memsets the struct, orphaning everything the failed attempt allocated, starting with the name allocated in bootdev_find_in_blk(). Each failed candidate therefore leaks its allocations on every scan. A single failing 'bootflow scan' on a sandbox MMC with a RAUC A/B layout leaks about 1 KB across ~30 abandoned candidates, and scans can be retried indefinitely from the U-Boot prompt. Free the bootflow when it failed and is not passed back to the caller. Add a check to the bootflow_rauc test that repeating a failing scan does not change the number of allocated bytes. Together with the previous RAUC fixes this makes the failed-scan path leak-free. Fixes: a8f5be178db5 ("bootstd: Add support for bootflows") Signed-off-by: Aristo Chen

bootstd: rauc: Clear bootmeth_priv after freeing it on error

2026-08-21T23:20:56Z

distro_rauc_read_bootflow() stores priv in bflow->bootmeth_priv before calling distro_rauc_scan_parts(). If the scan fails, the error path frees priv via distro_rauc_priv_free() but leaves bflow->bootmeth_priv pointing at the freed memory. With 'bootflow scan -a', failed bootflows are stored in the bootstd list, so the stale pointer is kept. The next scan (or any other bootflow removal) calls bootflow_free(), which frees bootmeth_priv again. On sandbox, dlmalloc catches the double free: common/dlmalloc.c:816: do_check_inuse_chunk: Assertion `inuse(p)' failed. The scan can fail this way whenever no slot has a valid filesystem, or when BOOT_ORDER names an unknown slot. Clear bflow->bootmeth_priv after freeing, as bootmeth_android already does. Extend the bootflow_rauc test to run a failing scan with -a and then rescan. Fixes: 284855320282 ("bootstd: rauc: Free memory during error handling") Signed-off-by: Aristo Chen

bootstd: rauc: Fix NULL dereference in get_slot()

2026-08-21T23:20:56Z

priv->slots is a NULL-terminated array of pointers, but get_slot() tests priv->slots[i]->name in its loop condition, dereferencing each entry before checking it against NULL. When slot_name does not match any configured slot, the loop reaches the terminator and dereferences a NULL pointer. This is reachable from the BOOT_ORDER environment variable: an entry naming a slot that is not listed in CONFIG_BOOTMETH_RAUC_PARTITIONS crashes U-Boot in distro_rauc_scan_parts() or distro_rauc_boot(). Since BOOT_ORDER is typically stored in a disk-resident environment written by the OS, a stray or corrupted value must not crash the bootloader. Test the array entry itself before using its name, as distro_rauc_priv_free() already does. Both callers already handle a NULL return. Extend the bootflow_rauc test to scan with a BOOT_ORDER naming an unconfigured slot. Without this fix the test crashes with SIGSEGV. Fixes: 7e5c2c782fb9 ("bootstd: Add implementation for bootmeth rauc") Signed-off-by: Aristo Chen

test: fit: verify dm-verity roothash is covered by the config signature

2026-08-10T18:32:41Z

A dm-verity protected filesystem image is not hashed by U-Boot; its integrity is delegated to the kernel, which trusts the roothash taken from the FIT dm-verity subnode. For that chain of trust to hold, the roothash (and salt) must be part of the region covered by the configuration signature, otherwise an attacker can replace both the filesystem and the roothash while keeping the signature valid. Add two independent checks of this property: - test/py/tests/test_fit_verity_sign.py signs a configuration that references a filesystem image carrying a dm-verity subnode, then confirms that tampering the roothash or the salt is rejected by fit_check_sign. A control that tampers a byte known to be signed proves the check can fail. A matching page is added under doc/develop/pytest/ so the module documentation is rendered with the rest of the generated docs. - test/boot/fit_verity.c gains a runtime unit test that builds the exact node list the configuration signature is computed over, turns it into hashed regions and checks both that the roothash bytes fall inside a signed region and that tampering them changes the hash. It needs no private key, so it also runs on real devices and uses the same hash path a device would. To let the unit test build the signed-region node list, rename the config node-list helper to fit_config_get_signed_nodes(), make it non-static and declare it in image.h. Signed-off-by: Daniel Golle Reviewed-by: Simon Glass

fit: prefer the default configuration on best-match ties

2026-07-24T16:46:16Z

With CONFIG_FIT_BEST_MATCH, fit_conf_find_compat() selects the configuration matching the most specific U-Boot compatible string; on equal matches the first listed configuration wins and the configurations node 'default' property is never consulted. A FIT whose configurations all share the same base devicetree compatible (e.g. one manifest carrying a base tree plus overlay combinations for a single board) therefore always boots the first configuration, silently ignoring the default chosen by the manifest author. Break score ties in favour of the default configuration. A strictly better compatible match still wins over it, and FITs without a default keep the current first-listed behaviour. Reviewed-by: Simon Glass Reviewed-by: Tom Rini Signed-off-by: Carlo Caione

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

test: vbe: cover vbe_read_fit() external-data bounds checks

2026-07-16T18:06:15Z

vbe_read_fit() rejects FITs whose external-data window extends past the trusted firmware area on disk by returning -E2BIG. Add two sandbox unit tests that construct synthetic FITs with attacker-controlled data-position and data-size values, write them to mmc1, and assert vbe_read_fit() catches each one before issuing the follow-up blk_read(). vbe_read_fit_oob_position uses a data-position past area_size, which trips the load_addr - addr > area_size clause. vbe_read_fit_oversize_data keeps data-position inside the area but picks a data-size that overruns area_size - (load_addr - addr), tripping the third clause. The two remaining bound clauses stay unreachable from a sandbox test. The load_addr < addr guard trivially holds when addr comes from CONFIG_VAL(TEXT_BASE), which is 0 on sandbox, and the FDT-region bound sits behind a !CONFIG_SANDBOX guard in vbe_read_fit(), so fdt_size stays 0 and that block is skipped in this test environment. The new file follows the existing bootstd VBE test layout and writes the FIT at block 16, past the version and nvdata blocks already used by bootstd_setup_for_tests(). Suggested-by: Simon Glass Reviewed-by: Simon Glass Signed-off-by: Aristo Chen

test: bootdev: scan with a broken high-priority device

2026-07-03T16:14:25Z

Add bootdev_hunt_fallthrough() test to verify that 'bootflow scan -l' falls back to a lower-priority bootdev when a higher-priority hunter fails. Introduce a simple 'sandbox-bootdev' device for the test. The new bootdev can be configured to produce an error at the hunting stage. Introduce new host_set_flags_by_label() API and a flags field to 'host_sb_plat' to simulate a bootdev hunter failure for the test. Adjust boot{dev,flow} tests which depend on bootdev hunters. Signed-off-by: Denis Mukhin Reviewed-by: Simon Glass

Merge patch series "various memory related fixups"

2026-06-15T17:04:48Z

rs@ti.com says: From: Randolph Sapp Nitpicks and fixes from the discovery thread on adding PocketBeagle2 support [1]. This does a lot of general setup required for the device, but these modifications themselves aren't device specific. For those specifically interested in PocketBeagle2 support and don't care about these details, my development branch is public [2]. That first patch may provoke some opinions, but honestly if that warning was still present I wouldn't have spent a week poking holes in both the EFI and LMB allocations systems. Please let me know if there is a specific usecase that it breaks though. [1] https://lore.kernel.org/all/DHHC66BBMD27.YHGIH43C6XBK@ti.com/ [2] https://github.com/StaticRocket/u-boot/tree/feature/pocketbeagle2 Link: https://lore.kernel.org/r/20260604155038.3182-1-rs@ti.com

test: boot: add a fdt reserved region check

2026-06-15T17:04:39Z

Add a image_fdt suite and a check for boot_fdt_add_mem_rsv_regions. This will ensure the user is properly informed of any reservation failures. It will also validate that reservations are cleaned up correctly when switching FDTs. Signed-off-by: Randolph Sapp Reviewed-by: Simon Glass Acked-by: Ilias Apalodimas