u-boot.git/boot, branch main

boot: image-fdt: Restore suppression of irrelevant ERROR message

2026-08-24T19:58:00Z

The commit 623f6c5b6ab7 ("boot: image-fdt: free old dtb reservations") removed the suppression of ERROR messages when -EINVAL was returned due to the memory region not being part of the LMB memory map. This causes an irrelevant ERROR message during boot, e.g.: Model: Radxa ROCK 3B [...] ERROR: reserving fdt memory region failed (addr=10f000 size=100 flags=2): -22 or Model: Rockchip RK3288 Asus Tinker Board S [...] ERROR: reserving fdt memory region failed (addr=fe000000 size=1000000 flags=4): -22 FDT correctly contains reserved-memory for 10f000 or fe000000 and U-Boot correctly does not make these regions available in the LMB memory map: memory[0] [0x200000-0xefffffff], 0xefe00000 bytes, flags: none memory[1] [0x100000000-0x1ffffffff], 0x100000000 bytes, flags: none or memory[0] [0x0-0x7fffffff], 0x80000000 bytes, flags: none With lmb_alloc_mem() and lmb_free() both returning -EFAULT when the requested memory region is not part of the LMB memory map it should be safe to ignore these errors when FDT memreserve and reserved-memory is being processed. Print -EFAULT errors using a debug message to restore suppression of this irrelevant ERROR message when memory region is not part of the LMB memory map. Fixes: 623f6c5b6ab7 ("boot: image-fdt: free old dtb reservations") Signed-off-by: Jonas Karlman Reviewed-by: Randolph Sapp

bootstd: android: bound the boot image read by its partition size

2026-08-12T07:46:11Z

read_slotted_partition() loads an Android boot/vendor_boot image into the load address, sizing the read from the image header: num_blks = DIV_ROUND_UP(image_size, desc->blksz); ... blk_dread(desc, partition.start, num_blks, map_sysmem(addr, 0)); image_size is priv->boot_img_size / priv->vendor_boot_img_size, taken from the boot image header and never bounded by the partition. A header claiming a size larger than the partition makes blk_dread read past the partition and write past the load buffer: an out-of-bounds write of attacker-controlled length on media a physical attacker can supply. It is reached during boot on a device where AVB does not gate the read (AVB disabled, or an unlocked device). Reject an image that does not fit in its partition before issuing the read. Both the boot and vendor_boot reads go through this function. Fixes: abadcda24b10 ("bootstd: android: don't read whole partition sizes") Signed-off-by: Shahriyar Jalayeri Reviewed-by: Simon Glass Link: https://patch.msgid.link/20260729-b4-android-bootmeth-oob-v1-1-31c3450ae0be@byteray.co.uk Signed-off-by: Mattijs Korpershoek

bootretry: only reinitialize retry_time when bootretry env variable has been touched

2026-08-10T20:47:50Z

Commit aa5ef3c0a752 ("bootretry: check for bootretry variable changes") broke the feature where one can define different keys for "delaying" versus "stopping" boot. The way the latter is implemented is by the code in autoboot.c calling bootretry_dont_retry() when the stop sequence has been detected, and that simply sets the retry_time variable in bootretry.c to -1. However, with the mentioned commit, that is unconditionally overridden on every command, since it gets re-initialized from either the bootretry environment variable or CONFIG_BOOT_RETRY_TIME, thus making "delay" and "stop" effectively the same. To fix that, while still picking up changes to the bootretry environment variable, use the proper mechanism for C code to be notified about changes to environment variables. Since the callback is invoked before the change has actually been done to the environment (callbacks can reject the change from taking effect), we cannot simply call the existing bootretry_init_cmd_timeout() from the callback, as its env_get() would not see the new value. Instead, refactor most of it to an internal bootretry_parse(), and call that with the new value (which is NULL in the case bootretry is being deleted, so that works exactly as it should). Signed-off-by: Rasmus Villemoes

Merge patch series "boot: fit: authenticate the dm-verity roothash"

2026-08-10T18:37:16Z

Daniel Golle says: A signed FIT configuration can delegate the integrity of a (potentially large) root filesystem image to the kernel's dm-verity instead of having U-Boot hash the whole payload at boot: the FIT carries a "dm-verity" subnode with the roothash, salt and block parameters, U-Boot passes the roothash to Linux through the dm-mod.create bootargs, and dm-verity then validates the filesystem block by block against it. For that to be safe the roothash has to be trusted, and in a signed configuration the only thing that establishes trust is the configuration signature. The roothash was not covered by it. fit_config_add_hash() collected the image node, its hash subnodes and its cipher subnode into the signed region, but not the dm-verity subnode, so the roothash, the sole integrity anchor for the filesystem, was left unsigned. The result is a verified-boot bypass for the root filesystem: an attacker who can rewrite the boot medium can replace the filesystem, recompute a matching dm-verity tree, write the new roothash into the unsigned dm-verity subnode, and the configuration signature still verifies. dm-verity then faithfully validates the malicious filesystem against the attacker's roothash. This series closes the gap. Link: https://lore.kernel.org/r/cover.1785276461.git.daniel@makrotopia.org

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

boot: fit: cover the dm-verity roothash with the config signature

2026-08-10T18:32:41Z

A dm-verity protected filesystem image is not hashed by U-Boot when it is loaded; its integrity is delegated to the kernel, which validates the filesystem on the fly against the roothash taken from the FIT dm-verity subnode. The roothash is therefore the sole integrity anchor for the filesystem, yet fit_config_add_hash() only adds the image node, its hash subnodes and its cipher subnode to the signed region, leaving the dm-verity subnode (roothash, salt and block parameters) unsigned. An attacker able to rewrite the boot medium could then replace both the filesystem and the roothash, recompute a matching dm-verity tree and keep the configuration signature valid, defeating verified boot for the root filesystem. Add the dm-verity subnode to the list of nodes covered by the configuration signature, both when signing (tools/image-host.c) and when verifying (boot/image-fit-sig.c), so the roothash and salt are authenticated together with the rest of the configuration. Signed-off-by: Daniel Golle Reviewed-by: Tom Rini Reviewed-by: Simon Glass

boot: fit: factor out node-path collection in fit_config_add_hash()

2026-08-10T18:32:41Z

Both the boot-side and host-side fit_config_add_hash() repeat the same sequence to append a node's path to the hashed-node list three times: for the image node, for each hash subnode and for the cipher subnode. Extract it into a helper, fit_config_add_node(), in each file, with no functional change. Signed-off-by: Daniel Golle Reviewed-by: Tom Rini Reviewed-by: Simon Glass

Merge tag 'u-boot-dfu-20260728' of https://git.u-boot-project.org/u-boot/custodians/u-boot-dfu

2026-07-28T13:52:00Z

u-boot-dfu-20260728 CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-dfu/-/pipelines/769 Android: * avb: Update libavb to AOSP 1.3.0 * avb: Fix memory leak on mmc_part * bootmeth_android: Fix memory leaks for AvbOps and verify-data * bootmeth_android: Fix out-of-bounds access in bootconfig parsing USB Gadget: * cmd: ums: Set serial# on iSerial device descriptor * dwc2: Set maxpacket_limit and endpoint capabilities to prepare for udc core migration * ci_udc: Fix ep type in ep_enable() * ci_udc: Set usb request status to handle complete callback * ci_udc: Ensure dtds are inactive before completing request

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

boot: android: fix AvbOps and verify-data leaks in AVB path

2026-07-24T12:43:05Z

run_avb_verification() allocates an AvbOps via avb_ops_alloc() but never frees it on any return path. Every Android boot attempt therefore leaks the AvbOpsData structure and, when CONFIG_OPTEE_TA_AVB is enabled, leaves the OP-TEE session open (it is only closed inside avb_ops_free()). In addition, the AvbSlotVerifyData returned by avb_slot_verify() is only released on the failure branches. The successful "return 0" paths (both the locked GREEN/OK case and the unlocked ORANGE/ERROR_VERIFICATION case) return without freeing it, leaking the whole out_data (cmdline and loaded partition metadata) on every good boot. Route all exit paths through a single cleanup label that frees both out_data and avb_ops. Fixes: 125d9f3306ea ("bootstd: Add a bootmeth for Android") Signed-off-by: Igor Opaniuk Reviewed-by: Mattijs Korpershoek Link: https://patch.msgid.link/20260712-avb-fix-memory-leaks-v1-1-51d6d5a42631@gmail.com Signed-off-by: Mattijs Korpershoek