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

Merge patch series "bootm: bound noload kernel decompression to the allocated buffer"

2026-06-17T15:54:27Z

Aristo Chen says: For a compressed kernel_noload image, bootm_load_os() allocates a decompression buffer of ALIGN(image_len * 4, SZ_1M) and then passes CONFIG_SYS_BOOTM_LEN (typically 128 MiB on arm64) to image_decomp() as the output limit. The decompressors honour whatever limit they are given, so a kernel that decompresses to more than four times its compressed size runs past the end of the allocated buffer and silently corrupts adjacent memory. A 4x compression ratio is at the edge of what modern compressors (zstd, xz) achieve on real kernels, and is trivially exceeded by crafted, highly compressible payloads, so this is reachable both accidentally and intentionally. The overflow can land on already-loaded boot artefacts (FDT, ramdisk, loadables), U-Boot's own data, or memory-mapped device registers; the existing post-decompression overlap check in bootm_load_os() only catches overlap with the FIT itself. Patch 1 plumbs the actual allocation size through to image_decomp() and handle_decomp_error() via a single decomp_len variable, so decompression stops at the buffer boundary and fails cleanly when the image is too large. The non-noload code path is unchanged and continues to use CONFIG_SYS_BOOTM_LEN. A clarifying note is printed when the failure is gated by the per-image buffer, so the generic "increase CONFIG_SYS_BOOTM_LEN" advice does not mislead. Patch 2 raises the noload-decompression headroom from 4x to 8x. The 4x factor is at the edge of what zstd and xz achieve on real kernels, so well-compressed vendor kernels can fail to boot at runtime once the bound is enforced. 8x covers them comfortably while remaining bounded. Patch 3 adds two sandbox py-tests against the per-image buffer at the final 8x value: one that exceeds the buffer and must be rejected, and one that matches the buffer exactly and must succeed (guarding the boundary). Tested on sandbox: both new tests pass; the existing test_fit_compressed_images_load (which covers the load-address path) and the other tests in test/py/tests/test_fit.py continue to pass. Link: https://lore.kernel.org/r/20260605154255.833334-1-aristo.chen@canonical.com

test/py: test kernel_noload decompression buffer overflow

2026-06-17T15:53:20Z

Add sandbox tests that exercise the per-image decompression buffer that bootm_load_os() allocates for a compressed kernel_noload image (ALIGN(image_len * 8, SZ_1M)). The overflow test builds a FIT whose decompressed size far exceeds the per-image buffer and asserts that 'bootm loados' rejects it with a decompression error rather than overflowing. The boundary test builds a FIT whose decompressed size equals the per-image buffer exactly and asserts that 'bootm loados' succeeds, guarding against an off-by-one rejection at the buffer limit. Signed-off-by: Aristo Chen

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

test_ut: add a ut_ubman fixture to clean up tests

2026-06-15T17:04:39Z

Add a ut_ubman fixture to clean up after certain problematic tests without negatively affecting the current assert based testing. Currently this catches "bootstd bootflow_cmd_boot" and "bootstd bootflow_scan_boot" ut_subtests, as these will change the sandbox state a little too much to be recoverable from. Signed-off-by: Randolph Sapp Reviewed-by: Simon Glass

image-fit: Validate external data offset and size

2026-06-12T21:38:27Z

fit_image_get_data() uses the data-position, data-offset, and data-size FIT properties without bounds checking. A crafted FIT image can specify values that cause out-of-bounds read during signature verification of an untrusted FIT. Validate that the external data offset and size are non-negative, and that the data region fits within the FIT image bounds. Signed-off-by: Anton Ivanov Reviewed-by: Simon Glass

image-fit-sig: Validate hashed-strings region size

2026-06-12T21:35:54Z

fit_config_check_sig() reads the hashed-strings property and uses its size value without validation when building the region list for signature verification. A crafted FIT image can specify an arbitrary size, causing the hash calculation to read beyond the end of the FIT image. The property length is also not checked, so a truncated hashed-strings property causes strings[1] to be read past the end of the property. This may result in the out-of-bounds read during signature verification of an untrusted FIT. Validate both the property length and that the declared strings region fits within bounds before adding it to the region list. Signed-off-by: Anton Ivanov

Merge patch series "tools: mkimage: fix get_basename crash on paths with dotted directories"

2026-06-11T18:00:55Z

Aristo Chen says: The get_basename() helper in tools/fit_image.c searches the entire input path independently for the last '/' and the last '.'. When the last '.' falls at an offset earlier than the last '/', for example "./mydt", "a.b/c" or "sub.d/leaf", 'end' points before 'start' and the computed length is negative. The size check uses signed comparison so the negative value flows unchanged into memcpy() (cast to size_t there) and mkimage segfaults during -f auto FIT generation. The helper is reached on every auto-FIT build via the -b, --fit-tee and --fit-tfa-bl31 file arguments. The first patch restricts the dot search to the substring that follows the last slash, which is the minimal fix and preserves the existing behaviour for typical inputs such as "arch/arm/dts/foo.dtb". The second patch adds a parametrized sandbox test under test/py/tests/test_fit_mkimage_validate.py that drives mkimage -f auto with each of the crashing inputs ("./mydt", "./sub.d/leaf", "./a.b/c") plus one control input ("./mydt.dtb"). The test reads the resulting /images/fdt-1 description back from the produced FIT via fdtget to verify get_basename()'s output matches the expected stripped basename. Reproducer that previously segfaulted and now produces a valid image: echo dummy > kernel.bin echo dummy > ./mydt ./tools/mkimage -f auto -A arm -O linux -T kernel -C none \ -a 0x80000000 -e 0x80000000 -n test \ -d kernel.bin -b ./mydt out.itb Verified by rebuilding tools/mkimage on master and running the command above with each of the four parametrized inputs. The three crash triggers all segfault before the fix and now produce the expected fdt-1 descriptions ("mydt", "leaf", "c"); the control input "./mydt.dtb" continues to produce "mydt" as before. Link: https://lore.kernel.org/r/20260526070336.23199-1-aristo.chen@canonical.com

test/py: cover get_basename crash on paths with dotted directories

2026-06-11T18:00:46Z

Add a parametrized regression test for the fix in the previous commit. The test invokes mkimage in auto-FIT mode (-f auto) with a -b argument whose directory component contains a '.' and whose leaf either lacks an extension or is a plain identifier. Before the fix these inputs caused get_basename() to compute a negative length and segfault inside memcpy. The test asserts that mkimage exits successfully and that the fdt sub-image description matches the expected stripped basename, covering "./mydt", "./sub.d/leaf", and "./a.b/c". A control input of "./mydt.dtb" is also exercised to confirm normal extension stripping still works. Signed-off-by: Aristo Chen

Merge patch series "allow control DTB to double as "FIT image""

2026-06-11T13:56:52Z

Rasmus Villemoes says: The commit message for patch 1 explains what it is I'd like to be able to do, but here's some more background: For a long time, we've embedded the boot script in the U-Boot binary by building a bootscript.itb, and using a .dtsi like / { config { bootscript = /incbin/("/path/to/bootscript.itb"); }; }; which in turn is mentioned in CONFIG_DEVICE_TREE_INCLUDES, that bootscript.itb FIT image has been embedded in U-Boot's control dtb. Running that was then a matter of doing fdt addr ${fdtcontroladdr} && fdt get addr bsaddr /config bootscript && source ${bsaddr} There are a couple of advantage of having the bootscript (and other script logic) embedded in the U-Boot binary. First, there's no need to figure out some separate partition to store the script in, and making sure that gets updated whenever the bootloader itself does. Second, one doesn't need to worry about verifying the script; whatever steps one needs to take to implement secure boot for U-Boot itself will by necessity also cover the control dtb (if nothing else then because that's where the public key for the kernel verification lives). And third, the boot script is automatically updated together with U-Boot itself; and if U-Boot is stored in an eMMC boot partition, that update is guaranteed to be atomic. Now with the stricter requirements of libfdt starting from v2026.04, the above command no longer worked, or only half the time, because the embedded FIT image may not land on an 8-byte aligned address. So that line had to be changed a little (line breaks added) fdt addr ${fdtcontroladdr} && fdt get addr bsaddr /config bootscript && fdt get size bssize /config bootscript && cp.b ${bsaddr} ${loadaddr} ${bssize} && source ${loadaddr} which is getting quite unwieldy. Then it struck me that one could perhaps simplify all of this quite a lot: Cut out the intermediate bootscript.itb, just create a .dtsi which directly puts a /images node inside the control dtb / { images { default = "bootscript"; bootscript { description = "Boot script"; data = /incbin/("/path/to/bootscript.sh"); type = "script"; compression = "none"; }; }; }; and treat the control dtb itself as a FIT image; so the command to put in $bootcmd becomes simply source ${fdtcontroladdr}:bootscript and embedding other pieces of callable scripts is quite trivial. And that almost works out-of-the-box, except for the fit_check_format() sanity check. Introduce a CONFIG_ knob that allows one to opt out of those sanity checks, for the special case of the address being checked being identical to gd->fdt_blob. Link: https://lore.kernel.org/r/20260602213013.558064-1-rv@rasmusvillemoes.dk