u-boot.git/boot/fdt_support.c, branch main

Merge patch series "fdt_support: validate property lengths in chosen and dma-range fixups"

2026-06-11T18:01:23Z

Aristo Chen 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_support: validate dma-ranges length in fdt_get_dma_range

2026-06-11T18:01:15Z

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

fdt_support: bound serialN alias length before copying to stack

2026-06-11T18:01:15Z

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

treewide: prefer func over FUNCTION and __PRETTY_FUNCTION__

2026-06-10T20:49:46Z

__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 Reviewed-by: Tom Rini

boot/bootfdt: Add smbios3-entrypoint to FDT for non-EFI boots

2025-12-02T22:34:27Z

The Linux kernel can discover SMBIOS tables through two primary methods: 1. Via EFI tables, when using EFI boot; 2. Via the 'smbios3-entrypoint' property in the /chosen node of the device tree. When U-Boot boots a Linux kernel using a non-EFI command ("bootm", "bootz", or "booti"), the kernel relies on the device tree to detect the hardware. If SMBIOS tables are available in U-Boot, they should be passed to the kernel via this device tree property. This patch modifies boot_fdt_prepare(), to inject the SMBIOSv3 table address into the device tree if there is a table generated by U-boot. The "board_fdt_chosen_smbios" is weak in order to leave the possibilty for specific boards to select custom SMBIOS addresses. The changes in this patch are added in the context of supporting this device tree property in linux kernel: https://lkml.org/lkml/2025/10/24/1393 Device tree schema was updated to include the "smbios3-entrypoint" node in pull request: https://github.com/devicetree-org/dt-schema/pull/177 Signed-off-by: Adriana Nicolae

Revert "fdt: Make sure there is no stale initrd left"

2025-10-03T13:45:20Z

This reverts commit 9fe2e4b46458f9c4ec6b8115ebf18b4b26fe6127. Commit 9fe2e4b46458 ("fdt: Make sure there is no stale initrd left") introduces a regression in case when U-Boot transfers control to an EFI app which acts as a subsequent bootloading program. Such an app might try to set "linux,initrd-start" and "linux,initrd-end" fdt properties, but by that time those properties are already removed by the code added in the mentioned commit. Particularly, the issue was observed on the E850-96 board where GBL EFI app [1] can't run Android successfully anymore. More specifically, the kernel can't see the ramdisk and panics with next messages: /dev/root: Can't open blockdev VFS: Cannot open root device "" or unknown-block(0,0): error -6 Please append a correct "root=" boot option; ... Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) fdt_initrd() function (where initrd dts properties are removed) is called two times: 1. First it's called by EFI boot manager (e.g. as a part of U-Boot Standard Boot mechanism) when it's installing FDT: fdt_initrd image_setup_libfdt efi_install_fdt efi_bootmgr_run efi_mgr_boot It's already enough for EFI app to malfunction. But then it's also called second time: 2. From the EFI app, via EFI DT fixup protocol: fdt_initrd image_setup_libfdt efi_dt_fixup struct efi_dt_fixup_protocol efi_dt_fixup_prot = { .fixup = efi_dt_fixup }; See [2] for specific GBL code which sets those fdt properties and then runs DT fixup protocol callback. This issue was discussed [3], but no action was taken since then. Revert this patch for now, until a proper solution can be found. [1] https://source.android.com/docs/core/architecture/bootloader/generic-bootloader/gbl-dev [2] https://android.googlesource.com/platform/bootable/libbootloader/+/refs/heads/gbl-mainline/gbl/libgbl/src/android_boot/mod.rs#208 [3] https://lists.denx.de/pipermail/u-boot/2025-July/593879.html Fixes: 9fe2e4b46458 ("fdt: Make sure there is no stale initrd left") Signed-off-by: Sam Protsenko

fdt: Make sure there is no stale initrd left

2025-06-12T22:13:51Z

Although if we don't setup an initrd, there could be a stale initrd setting from the previous boot firmware in the live device tree. So, make sure there is no setting left if we don't want an initrd. This can happen when booting on a Raspberry Pi. The boot firmware can happily load an initrd before us and configuring the addresses in the live device tree we get handed over. Especially the setting `auto_initramfs` in config.txt is dangerous. When enabled (default), the firmware tries to be smart and looks for initramfs files. Signed-off-by: Richard Weinberger

fdt: add support for adding pmem nodes

2025-03-26T11:28:08Z

One of the problems an OS may face, when running in EFI, is that a mounted ISO, after calling ExitBootServices goes away, if that ISO is resident in RAM memory as a ramdisk. ACPI has NFIT and NVDIMM support to provide ramdisks to the OS, but we don't have anything in place for DTs. Linux and device trees have support for persistent memory devices. So add a function that can inject a pmem node in a DT, so we can pass information on the ramdisk the OS. Signed-off-by: Masahisa Kojima Signed-off-by: Sughosh Ganu Reviewed-by: Ilias Apalodimas Signed-off-by: Ilias Apalodimas

common: fdt: hand over original fdt bootargs into board chosen handler

2025-01-14T21:41:56Z

Sometimes, it is necessary to provide an additional bootargs string to the kernel command line. We have a real scenario where one U-Boot blob needs to boot several kernel images: the vendor-patched kernel image and the latest upstream kernel image. The Amlogic (Meson architecture) tty driver has different tty suffixes in these kernels: the vendor uses 'ttySx', while the upstream implementation uses 'ttyAMLx'. The initial console setup is provided to the kernel using the kernel command line (bootargs). For the vendor kernel, we should use 'console=ttyS0,115200', while for the upstream kernel, it must be 'console=ttyAML0,115200'. This means we have to use different command line strings depending on the kernel version. To resolve this issue, we cannot use the CMDLINE_EXTEND kernel configuration because it is considered legacy and is not supported for the arm64 architecture. CMDLINE_EXTEND is outdated primarily because we can provide additional command line strings through the 'chosen/bootargs' FDT node. However, U-Boot uses this node to inject the U-Boot bootargs environment variable content, which results in U-Boot silently overriding all data in the 'chosen/bootargs' node. While we do have the board_fdt_chosen_bootargs() board hook to address such issues, this function lacks any FDT context, such as the original value of the 'chosen/bootargs' node. This patch introduces a read-only (RO) fdt_property argument to board_fdt_chosen_bootargs() to share the original 'chosen/bootargs' data with the board code. Consequently, the board developer can decide how to handle this information for their board setup: whether to drop it or merge it with the bootargs environment. Signed-off-by: Dmitry Rokosov Reviewed-by: Quentin Schulz

fdt_support: board_fdt_chosen_bootargs() should return const char*