Binarly found six U-Boot flaws, including two that enable code execution during boot image verification, impacting 50+ releases.Binarly’s research team has found six vulnerabilities in U-Boot, the open-source bootloader that runs on home routers, smart cameras, server management controllers, and a large portion of the embedded hardware that powers the internet. All six are triggered during the verification of a FIT image, which is the format U-Boot uses to package and validate the software it loads. Two of the vulnerabilities can lead to arbitrary code execution. Four can trigger a denial-of-service condition. The affected code has been present in U-Boot since version v2013.07, meaning over 50 stable releases are potentially impacted.U-Boot matters because it runs before the operating system, before any security software, before almost everything. “Because U-Boot is one of the first components to run during the boot process, it is highly security-sensitive: severe flaws at this stage can be used by a potential attacker to compromise everything that is loaded and executed afterwards.” reads the report published by Binarly. “Recognising the critical nature of this component, the Binarly Research team decided to examine the core functionality of the U-Boot project more closely. This research revealed six distinct vulnerabilities, ranging in impact from denial of service (DoS) to arbitrary code execution during the verification of an untrusted image.”Malicious code planted at this stage is extremely difficult to detect and nearly impossible to remove without physically reflashing the device’s storage chip.FIT stands for Flattened Image Tree. It’s the standard format U-Boot uses to bundle kernels, device trees, ramdisks, and firmware into a single package that also contains cryptographic hashes and signatures. FIT Signature Verification is the step that checks those signatures before deciding whether the image is trusted enough to execute. Binarly focused on this component specifically because breaking it would undermine the entire concept of verified boot, which is the mechanism meant to ensure only trusted code runs at each stage of startup. Several vulnerabilities in this same code path have been disclosed before, including CVE-2020-10648 and CVE-2021-27097, and Binarly found reason to believe there were more.BRLY-2026-037 stems from a function called fdt_find_regions, which walks the device tree structure inside a FIT image and builds a list of regions to hash. It calls fdt_get_name to retrieve node names during this walk. The problem is that fdt_get_name can return NULL in certain cases, specifically when processing an old-format FIT image whose version is below 0x10 and the node name contains no slash character. The code never checks for this and proceeds to use the NULL return value directly.For the root node, this causes an immediate crash. For child nodes, execution reaches a strcpy call that copies from the NULL pointer into a stack buffer allocated in the parent function. On most modern systems the zero page is unmapped and this also crashes. But on embedded devices it’s common for the zero page to be mapped, which means an attacker who can also control what sits at memory address 0x0 can turn this NULL dereference into a stack-based buffer overflow and from there into code execution. Binarly confirmed the vulnerability triggers in U-Boot’s sandbox build.BRLY-2026-038 builds on the same root cause but exploits a different consequence. When fdt_get_name fails, it writes a negative error code into the len argument. The surrounding code then uses len to advance a pointer through a stack buffer, but it never checks whether len is negative. A negative value moves the pointer backwards instead of forwards, producing a stack buffer underflow. “This underflow primitive enables us to move the end pointer backwards by 10 bytes (FDT_ERR_BADSTRUCTURE error code is -11, and *end++ = ‘/’ is executed on each iteration) for each malformed FDT entry until it reaches the return address of fdt_find_regions, which is possible because the target buffer lives in the stack frame of the parent fit_config_check_sig function.” continues the report. “From there, carefully chosen valid nodes supply the names that overwrite the return address of fdt_find_regions, along with the payload bytes.”Binarly demonstrated this working on a QEMU ARM build, printing a custom message to the console during U-Boot execution. The fix for both vulnerabilities is a single null check on the return value of fdt_get_name.BRLY-2026-039 involves the size of the strings region in a FIT image. During signature verification, the code reads this size from a property in the image called “hashed-strings” without checking whether the declared size actually fits within the image boundaries. An attacker sets this value to 0xFFFFFFFF and the hashing routine attempts to read nearly four gigabytes of data, quickly running past the end of the image into unmapped memory and crashing the bootloader.BRLY-2026-040 is another null pointer dereference in fdt_find_regions, this time from a different code path. When the function encounters a property tag in the device tree, it calls fdt_get_property_by_offset to read the property header. For FIT images with a version below 0x10, this function returns NULL without attempting to parse the property. The code immediately dereferences the returned pointer without checking it, crashing U-Boot on any platform where the zero page is unmapped.BRLY-2026-041 involves FIT images that store payload data externally, referenced by position and size values embedded in the image. “All three properties – data-position, data-offset and data-size – are fully controlled by the attacker, and none of them are checked against the actual size of the FIT image. The data pointer and size produced here then travel through the same hashing path as it was described for BRLY-2026-039 above.” continues the report. “This provides attackers with two straightforward methods of crashing the bootloader: pointing the data region outside the mapped memory through data-position/data-offset, or requesting an enormous data-size. For example, with a provided size of 0xFFFFFFFF the hashing routine reads far beyond the image bounds.”An attacker can crash the bootloader either by pointing the data region outside mapped memory or by declaring a data size of 0xFFFFFFFF.BRLY-2026-042 is triggered even earlier than the others, before signature verification starts, during FIT format validation. A function called fdt_check_no_at walks the entire FIT image tree recursively to look for node names containing an @ symbol, a character that can cause logical problems in libfdt’s node matching. The recursion stops only when it runs out of subnodes, and the depth limit inherited from the preceding check allows trees nested up to INT_MAX levels deep. Adding one more nesting level to a FIT image costs 12 bytes. Each recursive call consumes at least 16 bytes of stack space. The math isn’t complicated. “This ensures that the stack will be exhausted regardless of the size of the device’s RAM.” states Binarly.The fix adds a depth counter that rejects images once nesting exceeds 32 levels.A reasonable assumption is that exploiting a bootloader vulnerability requires physical access to the hardware. Binarly pushes back on this directly, pointing to earlier research on Supermicro BMC firmware as a counter-example. Server BMCs expose remote administration interfaces, and Binarly has previously shown that an attacker with access to those interfaces can bypass firmware update validation and force the legitimate update mechanism to flash a malicious image. The same principle applies broadly: any device that accepts firmware updates over a network, even one that performs validation, may be reachable without anyone touching the hardware.All six patches have been accepted upstream and are available in U-Boot’s master branch. Binarly prepared the patches themselves after the initial disclosure encountered some friction with the project’s maintainers. Organizations running devices built on U-Boot, particularly server hardware with BMC controllers, should apply the patches through their vendor’s firmware update process as soon as updates become available. Proof-of-concept FIT images and reproduction steps for all six vulnerabilities are included in Binarly’s individual advisories.“The PoC FIT image generation script and the steps required to reproduce the issue are fully detailed in the advisory for this vulnerability.” concludes the report. “The fix adds a depth counter to fdt_check_no_at, rejecting the image once the nesting reaches FDT_MAX_DEPTH, which is defined in boot/fdt_region.c and is equal to 32.”Follow me on Twitter: @securityaffairs and Facebook and MastodonPierluigi Paganini(SecurityAffairs – hacking, U-Boot)