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
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 <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
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: 125d9f3306 ("bootstd: Add a bootmeth for Android")
Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Link: https://patch.msgid.link/20260712-avb-fix-memory-leaks-v1-1-51d6d5a42631@gmail.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
For a compressed kernel_noload image, bootm_load_os() allocates a
per-image decompression buffer of ALIGN(image_len * 8, SZ_1M) rather
than the global CONFIG_SYS_BOOTM_LEN. When decompression fails on that
path, handle_decomp_error() still prints
Image too large: increase CONFIG_SYS_BOOTM_LEN
which is misleading: increasing CONFIG_SYS_BOOTM_LEN does not help
because the smaller per-image buffer is the actual bound. Commit
2ff26c1e378d ("bootm: fix overflow of the noload kernel decompression
buffer") worked around this by printing a follow-up note right after
handle_decomp_error() returned, but the boot log then reads as two
contradictory sentences.
Introduce enum bootm_decomp_limit and pass it into
handle_decomp_error() so the helper picks the right message in one
place. For the per-image path it now prints
Image too large for the per-image decompression buffer (0x100000 bytes)
quoting the actual buffer size; the global path is unchanged. Drop the
trailing note in bootm_load_os() so only one line is printed.
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When android_image_get_vendor_bootimg_size is called, its buffer is only
allocated with enough space for the bootconfig header, but the
android_vendor_boot_image_v3_v4_parse_hdr helper attempts to append a
bootconfig trailer to it, causing an out-of-bounds access and heap
corruption in some cases (e.g. triggered in sandbox test builds when
extra bootmeths are added, resulting in a segfault of the sandbox
process).
Skip the dangerous memcpy operations altogether when the
android_vendor_boot_image_v3_v4_parse_hdr helper is only called for size
calculation purposes, and only append the bootconfig trailer when called
from the actual bootconfig parsing code path.
Fixes: 57e405e1f4 ("android: boot: support bootconfig")
Signed-off-by: Alexey Charkov <alchark@flipper.net>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://patch.msgid.link/20260708-image-android-oob-fix-v1-1-a96de8ccd25e@flipper.net
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Aristo Chen <aristo.chen@canonical.com> 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_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 <sjg@chromium.org>
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
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 <james.hilliard1@gmail.com>
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 <dmukhin@ford.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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 <nora.schiffer@ew.tq-group.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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 <nora.schiffer@ew.tq-group.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
`flush_start` must be set after `load` has been assigned.
Fixes: 69544c4fd8 ("bootm: Support kernel_noload with compression")
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit 103b1e7ce8 ("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 <sjg@chromium.org>
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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 <jbx6244@gmail.com>
Currently, the bi_dram[] information is stored in the board info
structure (bd). Because bd is only valid after reserve_board(),
dram_init_banksize() must be called late in the initialization process.
This limitation is problematic, as it forces us to rely on a variety of
bespoke functions to determine board RAM, bank memory sizes, and other
early setup requirements.
By moving bi_dram[] into the global data (gd), we can run it earlier.
This is particularly convenient since boards define their own
dram_init_banksize() routines, which do not always rely on parsing
Device Tree (DT) memory nodes.
Additionally, U-Boot defaults to relocating to the top of the first memory
bank. While boards currently use custom functions to override this
behavior, having the DRAM bank information available earlier in gd makes
relocating to a different bank trivial and standardizes the process.
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Michal Simek <michal.simek@amd.com> # Versal Gen 2 Vek385
Tested-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Francesco Valla <francesco@valla.it> says:
This patch set contains a collection of small fixes and cleanups for the
"full" FIT loader that can be used for the SPL. The main beneficiary is
the falcon boot flow, but the same loader can be used also for U-Boot
proper.
Patch 1 was part of another set, but I decided to put it here for a
better separation between plumbing (here) and new features (there). I
kept the Reviewed-by tag collected from Simon in that occasion.
Patch 6 introduces a new unit test covering most of the code that is
being cleaned up.
The set was tested on a i.MX93 FRDM, both with and without signature and
to boot both U-Boot proper and the Linux kernel directly (i.e., falcon
boot).
Link: https://lore.kernel.org/r/20260604-spl_fit_full_cleanup-v1-0-ec036b5872e2@valla.it
Align the behavior of fit_image_verify() called in SPL to the one in
full U-Boot. In particular, this function is called when both
CONFIG_SPL_LOAD_FIT_FULL and CONFIG_SPL_FIT_SIGNATURE are set (which can
happen e.g. in case of secure falcon boot).
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Francesco Valla <francesco@valla.it>
For a compressed kernel_noload image, bootm_load_os() allocates a buffer
of ALIGN(image_len * 4, SZ_1M). The 4x factor is at the edge of what
modern compressors (zstd, xz) achieve on real kernels, so a
well-compressed vendor kernel can fail to boot at runtime with no
intervening warning.
Bump the headroom to 8x. The buffer is still bounded by the compressed
image size, and the SZ_1M alignment keeps the overhead below 1 MiB on
small kernels.
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
For a compressed kernel_noload image, bootm_load_os() allocates a
decompression buffer sized to ALIGN(image_len * 4, SZ_1M), assuming the
kernel compresses by no more than a factor of four. It then passes
CONFIG_SYS_BOOTM_LEN, rather than the size of that buffer, to
image_decomp() as the output limit. The decompressors honour the limit
they are given, so a kernel that decompresses to more than four times
its compressed size is written past the end of the allocated buffer and
corrupts adjacent memory.
Pass the allocation size to image_decomp() and handle_decomp_error() so
decompression stops at the buffer boundary and fails cleanly when the
image is too large, instead of overflowing. The regular non-noload
paths are unchanged and continue to use CONFIG_SYS_BOOTM_LEN. When the
failure is triggered by the smaller per-image buffer, print a note so
that handle_decomp_error()'s generic advice to increase
CONFIG_SYS_BOOTM_LEN does not mislead the reader.
Fixes: 69544c4fd8 ("bootm: Support kernel_noload with compression")
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Aristo Chen <aristo.chen@canonical.com> 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
For a compressed kernel_noload image, bootm_load_os() allocates a buffer
of ALIGN(image_len * 4, SZ_1M). The 4x factor is at the edge of what
modern compressors (zstd, xz) achieve on real kernels, so a
well-compressed vendor kernel can fail to boot at runtime with no
intervening warning.
Bump the headroom to 8x. The buffer is still bounded by the compressed
image size, and the SZ_1M alignment keeps the overhead below 1 MiB on
small kernels.
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
For a compressed kernel_noload image, bootm_load_os() allocates a
decompression buffer sized to ALIGN(image_len * 4, SZ_1M), assuming the
kernel compresses by no more than a factor of four. It then passes
CONFIG_SYS_BOOTM_LEN, rather than the size of that buffer, to
image_decomp() as the output limit. The decompressors honour the limit
they are given, so a kernel that decompresses to more than four times
its compressed size is written past the end of the allocated buffer and
corrupts adjacent memory.
Pass the allocation size to image_decomp() and handle_decomp_error() so
decompression stops at the buffer boundary and fails cleanly when the
image is too large, instead of overflowing. The regular non-noload
paths are unchanged and continue to use CONFIG_SYS_BOOTM_LEN. When the
failure is triggered by the smaller per-image buffer, print a note so
that handle_decomp_error()'s generic advice to increase
CONFIG_SYS_BOOTM_LEN does not mislead the reader.
Fixes: 69544c4fd8 ("bootm: Support kernel_noload with compression")
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
rs@ti.com <rs@ti.com> says:
From: Randolph Sapp <rs@ti.com>
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
Add a free flag and an initial call to free allocations covered by the
global FDT. This assumes that all calls to boot_fdt_add_mem_rsv_regions
occur before the transition to the new device tree, thus we can access
the currently active device tree through the global data pointer.
This allows us to clearly indicate to the user when a device tree
reservation fails. How we handle this can still use some improvement.
Right now we'll keep the default behavior and try to boot anyway.
Fixes: 5a6aa7d591 ("boot: fdt: Handle already reserved memory in boot_fdt_reserve_region()")
Signed-off-by: Randolph Sapp <rs@ti.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Fixes: tag with a 12-char hash:
Fixes: 5a6aa7d591 ("boot: fdt: Handle already reserved memory in
The boot selection rules state that a slot is bootable if it is not
corrupted and either has tries remaining or has already booted
successfully. However, slots that have tries_remaining == 0 and
successful_boot == 1 will be disregarded when picking the slot to
attempt.
Updates the selection logic so slots marked successful remain eligible
even when their tries counter is zero. Debug message now also includes
the successful_boot value.
Signed-off-by: Colin Pinnell McAllister <colinmca242@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Link: https://patch.msgid.link/20260525003158.11319-1-colinmca242@gmail.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
fdt_get_name() can return NULL and set len to a negative error code.
fdt_find_regions() does not check for this, leading to a potential NULL
pointer dereference and a buffer out-of-bounds write during signature
verification of an untrusted FIT. fdt_next_region(), fdt_check_full(),
and display_fdt_by_regions() also lack validation.
Add NULL checks and propagate the error code from fdt_get_name()
to the caller.
Signed-off-by: Anton Ivanov <anton@binarly.io>
Reviewed-by: Simon Glass <sjg@chromium.org>
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 <anton@binarly.io>
Reviewed-by: Simon Glass <sjg@chromium.org>
fdt_check_no_at() recurses into every subnode without a depth
limit. A deeply nested FIT image can exhaust the stack and crash
U-Boot during signature verification of an untrusted FIT.
Add a depth check using FDT_MAX_DEPTH to bound the recursion.
Signed-off-by: Anton Ivanov <anton@binarly.io>
fdt_get_property_by_offset() returns NULL for FDT with version
less than 0x10. fdt_find_regions() dereferences the result without
checking, leading to a NULL pointer dereference during signature
verification of an untrusted FIT. fdt_add_alias_regions() and
fdt_next_region() also lack validation.
Add NULL checks before accessing the returned property pointer.
Also add a missing NULL check for fdt_string() in
fdt_add_alias_regions() and fdt_next_region().
Signed-off-by: Anton Ivanov <anton@binarly.io>
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 <anton@binarly.io>
Aristo Chen <aristo.chen@canonical.com> says:
boot/fdt_support.c contains a number of helpers that fix up the kernel
devicetree handed to the OS during bootm/booti. Several of those
helpers consume fdt_getprop() results without validating the returned
length against the per-entry size implied by the surrounding cell-count
arithmetic. When the OS devicetree is not signature-verified, for
example an unsigned FIT, a DT loaded from $fdtaddr or $fdtcontroladdr,
or a DT supplied over a network boot, the property is
attacker-influenced and the missing checks turn into out-of-bounds
reads or writes on the FDT blob and on stack buffers.
The first patch targets fdt_fixup_stdout(). The function copies the
value of /aliases/serialN into a fixed 256-byte stack buffer before
publishing it as /chosen/linux,stdout-path, but does not check that
the property fits. The patch rejects an oversized property with a
debug-only message and -FDT_ERR_NOSPACE so the unbounded memcpy
cannot run.
The second patch addresses fdt_get_dma_range(). The function reads
one full dma-ranges entry of (na + pna + ns) * sizeof(u32) bytes
after checking only that the returned length is non-zero. A
dma-ranges property shorter than one entry causes the subsequent
fdt_read_number() and fdt_translate_dma_address() calls to read past
the property within the FDT blob. The patch validates the length
against one full entry and returns -EINVAL when the property is too
short, matching the existing failure paths in this function.
Both rejection paths use debug() rather than printf() so production
builds do not pay any .text or .rodata growth for the new diagnostic
text. Measured against master on real cross-compiled targets, the v1
printf form added 88 bytes of .text on CMPCPRO_defconfig (which links
the fdt_fixup_stdout check) and 119 bytes on rpi_arm64_defconfig
(which links fdt_get_dma_range). The v2 debug form adds 0 bytes on
CMPCPRO and 20 bytes on rpi_arm64; the 20-byte residual is the
length-check branch itself, not the diagnostic.
Build tested with kontron_sl28_defconfig (aarch64),
CMPCPRO_defconfig (powerpc, which enables both
CONFIG_OF_STDOUT_VIA_ALIAS and CONFIG_CONS_INDEX and therefore links
the new bounds check in fdt_fixup_stdout), rpi_arm64_defconfig
(aarch64, links fdt_get_dma_range) and sandbox_defconfig. All builds
are clean and scripts/checkpatch.pl reports no errors, warnings, or
checks on either patch.
Link: https://lore.kernel.org/r/20260526020917.8438-1-aristo.chen@canonical.com
fdt_get_dma_range() fetches the dma-ranges property with fdt_getprop()
and checks only that the length is non-zero before reading one full
entry from it. The entry size depends on na, pna and ns cells returned
by count_cells, which come from the parent buses in the devicetree.
A dma-ranges property shorter than (na + pna + ns) * sizeof(u32) bytes
causes fdt_read_number() and fdt_translate_dma_address() to read past
the end of the property within the FDT blob, an out-of-bounds read of
attacker-influenced data when the OS devicetree is not signature
verified.
Reject the property when its length is smaller than one full entry and
return -EINVAL, matching the existing failure paths in this function.
Use debug() rather than printf() for the rejection text so that
production builds do not pay any .text or .rodata growth for the new
diagnostic.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
fdt_fixup_stdout() reads the path stored in /aliases/serialN with
fdt_getprop() and then memcpys it into a fixed 256-byte stack buffer.
The length returned by libfdt is the raw on-disk property size and is
not bounded by any console-path convention, so an oversized property
in a malformed or untrusted devicetree overflows the buffer with
attacker-controlled length and contents. The "/* long enough */"
comment next to tmp[] codifies an unchecked assumption.
Reject lengths that exceed sizeof(tmp) with a debug-only message and
return -FDT_ERR_NOSPACE. The fixup runs during fdt_chosen() on every
booted kernel when CONFIG_OF_STDOUT_VIA_ALIAS is enabled, and when
the OS devicetree is not signature-verified the property is reachable
from an attacker-influenced blob. Using debug() rather than printf()
keeps the rejection text out of production builds so there is no
.text or .rodata growth on space-constrained targets.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
The boot_os[] table in bootm_os.c is a sparse array whose compile-time
size is set by its largest designated initializer (IH_OS_ELF), giving
it IH_OS_ELF + 1 entries. The accessor bootm_os_get_boot_func() returns
boot_os[os] without any bound check, even though the caller in
bootm_run_states() passes images->os.os straight through. That field is
populated by image_get_os() from the raw 8-bit ih_os byte of a legacy
uImage, and by fit_image_get_os() for a FIT, neither of which clamps
the value against the table size.
An attacker-supplied image whose OS field falls outside the populated
range therefore drives an out-of-bounds read of boot_os[]. The caller
only rejects a NULL return, so a non-NULL adjacent global is accepted
as a valid handler and invoked through the indirect call in
boot_selected_os(), turning an unsigned image with a malformed header
into a jump through an attacker-influenced function pointer. FIT
signature verification covers the os property and mitigates this path
for signed images, but legacy bootm and unsigned FIT do not.
Reject out-of-range indices in bootm_os_get_boot_func() so the existing
NULL handling in bootm_run_states() reports an unsupported OS and
declines to boot the image.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Rasmus Villemoes <rv@rasmusvillemoes.dk> 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
Having scripts embedded one way or the other in the U-Boot binary
means they are automatically verified/trusted by whatever mechanism
verifies U-Boot.
Writing those scripts in the built-in environment leads to
backslatitis and missing or wrong quoting and is generally not very
readable or maintainable.
Maintaining scripts in external files allows one
to have both syntax highlighting and to some extent apply shellcheck
on it (though U-Boot's shell is of course not quite POSIX sh, so some
'#shellcheck disable' directives are needed). Getting those into the
U-Boot binary is then a matter of having a suitable .dtsi file such as
/ {
images {
default = "boot";
boot {
description = "Bootscript";
data = /incbin/("boot.sh");
type = "script";
compression = "none";
};
factory-reset {
description = "Script for performing factory reset";
data = /incbin/("factory-reset.sh");
type = "script";
compression = "none";
};
};
};
and making that part of CONFIG_DEVICE_TREE_INCLUDES, so that U-Boot's
control DTB effectively doubles as a FIT image containing a few
"script" entries. At run-time, one's default bootcommand can then
simply be
source ${fdtcontroladdr}:boot
Except of course that the control DTB is in fact not quite a FIT
image. The lack of timestamp and description properties could
potentially be worked around (by just adding those via that same
.dtsi), but the no-@ check is not possible to get around. But since
the control dtb is by definition trusted, we can make an exception for
that particular address, if the new CONTROL_DTB_AS_FIT config option
is enabled.
One can of course build an ordinary FIT image with those
scripts. However, that requires extra steps in the boot command for
loading that script from storage, requires one to use "configurations"
for pointing at a single script to run, and signing the FIT image
using the same key used for verifying the kernel. Moreover, in certain
situations, such as bootstrapping/production, there is no place to
load that FIT image from, and it is much simpler to just have the
necessary scripts be part of the U-Boot image itself.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
__FUNCTION__ and __PRETTY_FUNCTION__ are gcc extensions that predate
the C99 __func__ identifier. scripts/checkpatch.pl emits a warning
for any new use of __FUNCTION__ and recommends __func__ instead. In
C (unlike C++) __PRETTY_FUNCTION__ is identical to __func__ because
C function names do not carry signature information, so the
distinction has no behavioural effect here. The majority of the tree
already uses __func__, but a handful of older files in arch/, board/,
boot/, drivers/, examples/ and include/ still carry the gcc spellings
(55 occurrences of __FUNCTION__ across 19 files plus one
__PRETTY_FUNCTION__ in drivers/usb/musb-new/omap2430.c). Convert
them all to the C99 form so the tree is consistent and new patches
in these areas do not have to follow an outdated local style.
Ten "Unnecessary ftrace-like logging - prefer using ftrace" warnings
remain on the printf("%s\n", __func__) and dbg("%s\n", __func__)
function-entry traces in drivers/net/rtl8169.c (behind DEBUG_RTL8169*
preprocessor guards) and drivers/usb/host/ohci-hcd.c. checkpatch
matches the literal "%s\n", __func__ shape regardless of the wrapper,
so silencing those warnings would require changing the debug message
text or removing the traces entirely.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
ulong is 64 bits on 64-bit platforms. Hence, simple_xtoa can
produce up to 16 hex characters + NULL byte. The initrd_filesize
buffer is only 10 bytes which can cause a buffer overflow on
every PXE boot that loads an initrd on an address greater than
4GB.
Increase buffer size to 17 bytes to hold the maximum hex
representation of a 64-bit address.
Signed-off-by: Francois Berder <fberder@outlook.fr>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
Tom Rini <trini@konsulko.com> says:
This series does a few small but important cleanups to how we check for,
and initialize a bloblist. The first thing is that the way things are
done today, our HANDOFF code can only work with a fixed bloblist
location, so express that requirement in Kconfig. Next, we demote the
scary message about "Bloblist at ... not found" to a debug because we
most often see that because the bloblist doesn't (and can't) exist yet.
Finally, we remove bloblist_maybe_init and split this in to an exists
and a real init. This results in practically no growth (between 8 bytes
growth to 12 bytes saved, with some outliers saving much more thanks to
knowing it's impossible to have been passed a bloblist yet). This also
cleans up some of the code around checking for / knowing about a
bloblist existing.
Link: https://lore.kernel.org/r/20260519162225.770071-1-trini@konsulko.com
In h_read_settings, val variable could be NULL due to
ofnode_read_prop returning an error. This variable
would then be used as the src in strcpy.
Add a NULL check after calling ofnode_read_prop.
Signed-off-by: Francois Berder <fberder@outlook.fr>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add fit_verity_build_cmdline(): when a FILESYSTEM loadable carries a
dm-verity subnode, construct the dm-mod.create= kernel cmdline parameter
from the verity metadata (block-size, data-blocks, algo, root-hash,
salt) and append it to bootargs.
Also add dm-mod.waitfor=/dev/fit0[,/dev/fitN] for each dm-verity device
so the kernel waits for the underlying FIT block device to appear before
setting up device-mapper targets. This is needed when the block driver
probes late, e.g. because it depends on NVMEM calibration data.
The dm-verity target references /dev/fitN where N is the loadable's
index in the configuration -- matching the order Linux's FIT block
driver assigns block devices. hash-start-block is read directly from
the FIT dm-verity node; mkimage ensures its value equals num-data-blocks
by invoking veritysetup with --no-superblock.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Aristo Chen <aristo.chen@canonical.com> says:
This series ends with replacing the verbose fdt_next_node() + ndepth
idiom in boot/image-fit.c with fdt_for_each_subnode(), bringing the
file in line with boot/image-fit-sig.c. Six of the seven sites in
image-fit.c predate the macro by 2-6 years; the seventh was
copy-pasted from a neighbour in 2015 just after the macro landed.
The old idiom is legacy, not a deliberate technical choice.
Converting straight to the macro turned out to need a prerequisite,
which is patch 1. fit_print_contents() reads the default-config
property using the loop variable left over after iterating /images
children. With /images defined first in the source (the conventional
layout) libfdt's walker happens to leave that variable pointing at
/configurations and the read works. With /configurations defined
first the read returns NULL and the "Default Configuration" line is
silently omitted. fdt_for_each_subnode()'s post-loop value is
unconditionally a negative error code, so a naive conversion would
have made the missing line the unconditional behaviour. Patch 1
reads the property from confs_noffset directly and removes the
layout dependency.
Patch 2 adds a regression test for the configs-before-images
layout, which had no coverage.
Patch 3 is the mechanical conversion at all seven sites,
equivalence-preserving as described in the per-patch message.
Link: https://lore.kernel.org/r/20260508213217.3807786-1-aristo.chen@canonical.com
Replace the verbose fdt_next_node() + ndepth pattern with the
fdt_for_each_subnode() macro at all seven sites in boot/image-fit.c
where the loop only ever processes direct children. The macro is
already defined in <linux/libfdt.h> and used in boot/image-fit-sig.c,
so this brings image-fit.c in line with the rest of the FIT code.
The conversions are equivalence-preserving:
- fit_get_subimage_count(): the depth-1 filter and the macro are
both restricted to direct children.
- fit_conf_print(): the parameter is named noffset, so the loop
now uses sub_noffset to keep the parent reference stable.
- fit_print_contents(): the count reset that lived inside the for
initialiser is moved out as an explicit assignment before each
loop, so the second loop still starts from zero.
- fit_image_print(): straightforward replacement.
- fit_all_image_verify(): same shape as the print loops, with the
count reset moved out as an explicit assignment before the loop.
- fit_conf_find_compat(): the body's "if (ndepth > 1) continue"
guard is redundant once the macro is in use, and is dropped.
No behaviour changes outside of these mechanical reductions. Local
ndepth declarations that are no longer referenced are removed.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In fit_print_contents() the default configuration's unit name is read by
calling fdt_getprop() with noffset rather than confs_noffset. Today this
happens to work by coincidence: the preceding loop walks /images using
fdt_next_node(), and when iteration leaves the subtree libfdt returns
the offset of the next sibling in DFS order, which by FIT layout
convention is /configurations. The depth counter then drops below zero
and the loop exits with noffset still pointing at /configurations.
This relies on /images and /configurations being adjacent siblings and
on the implementation detail of fdt_next_node()'s post-exhaustion
return value. It also blocks a follow-up conversion to
fdt_for_each_subnode(), whose post-loop loop variable is a negative
error code rather than a valid offset.
Use confs_noffset directly, which the comment immediately above the
call already names as the source.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In the case where a bootdev does not have a custom get_bootflow function
but instead relies on default_get_bootflow to provide one,
bootdev_get_bootflow was not handling the case where ops was simply not
set. Restructure the function to check for "ops && ops->get_bootflow"
and add appropriate log_debug calls for both cases.
Signed-off-by: Tom Rini <trini@konsulko.com>
A number of our boards no longer boot with v2026.04, ironically as a
result of the effort to ensure 8-byte alignment of the dtb passed to
the kernel and getting rid of the fdt_high=0xffffffff.
The problem exists when the FIT image does specify a (properly
aligned) load address to use for the fdt. For example, we have
fdt-am335x-boneblack.dtb {
description = "Flattened Device Tree blob";
data = /incbin/(...);
...
load = <0x88000000>;
}
Now, with v2026.04 and depending on just exactly where that data ends
up, in a good case we see
Loading fdt from 0x8a8c6e10 to 0x88000000
Booting using the fdt blob at 0x88000000
Working FDT set to 88000000
Loading Kernel Image to 86008000
WARNING:
The 'fdt_high' environment variable is set to ~0. This is known to cause
boot failures due to placement of DT at non-8-byte-aligned addresses.
This system will likely fail to boot. Unset the 'fdt_high' environment
variable and submit a fix upstream.
Using Device Tree in place at 88000000, end 8801af2f
Working FDT set to 88000000
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
and the board boots (though with that ominous warning). However,
modifying the .its file a little, e.g. just removing the word "blob"
from the description, we end up with
Loading fdt from 0x8a8c6e14 to 0x88000000
Booting using the fdt blob at 0x9df94718
Working FDT set to 9df94718
Loading Kernel Image to 86008000
WARNING:
The 'fdt_high' environment variable is set to ~0. This is known to cause
boot failures due to placement of DT at non-8-byte-aligned addresses.
This system will likely fail to boot. Unset the 'fdt_high' environment
variable and submit a fix upstream.
Failed to reserve memory for fdt at 0x9df94718
FDT creation failed!
resetting ...
Notice how the "Loading fdt from" line still claims to load the fdt to
that 0x88000000 address, but since this "else if" clause looks at the
source address (buf) and comes before the "else if (load != data)"
clause, we end up doing the "allocate another buffer to use as target"
instead of actually copying to 0x88000000, but then the "fdt_high=~0"
logic in boot_relocate_fdt() obviously fails to do an lmb-reservation
of that area, and the boot fails.
When there's no load= property in the fdt node, this should not change
anything. But when there is, it is the alignment of that target which
is relevant, not the alignment of the fdt blob within the FIT
image. With this patch applied, we instead get the expected
Loading fdt from 0x8a8c6e14 to 0x88000000
Booting using the fdt blob at 0x88000000
Working FDT set to 88000000
Loading Kernel Image to 86008000
WARNING:
The 'fdt_high' environment variable is set to ~0. This is known to cause
boot failures due to placement of DT at non-8-byte-aligned addresses.
This system will likely fail to boot. Unset the 'fdt_high' environment
variable and submit a fix upstream.
Using Device Tree in place at 88000000, end 8801af2f
Working FDT set to 88000000
Starting kernel ...
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Fixes: 8fbcc0e0e8 ("boot: Assure FDT is always at 8-byte aligned address")
Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini
Carlo CaioneandTom Rini
Igor OpaniukandMattijs Korpershoek
Aristo ChenandTom Rini
Alexey CharkovandMattijs Korpershoek
James HilliardandTom Rini
Denis MukhinandTom Rini
Nora SchifferandTom Rini
Johan JonkerandTom Rini
Ilias ApalodimasandTom Rini
Francesco VallaandTom Rini
Randolph SappandTom Rini
Colin Pinnell McAllisterandMattijs Korpershoek
Anton IvanovandTom Rini
Rasmus VillemoesandTom Rini
Francois BerderandJerome Forissier
Daniel GolleandTom Rini
Rasmus VillemoesandTom Rini