Six U-Boot FIT Signature Verification Flaws Expose Devices to Code Execution and DoS Attacks

Six newly disclosed U-Boot vulnerabilities can let attackers crash devices or, in some cases, execute code in the bootloader before the operating system starts.

The flaws affect U-Boot’s FIT signature verification logic, a key part of verified boot on many embedded systems. According to the Binarly Research analysis, the issues sit in code paths that process untrusted FIT images before verification finishes.

That makes the bugs important for device makers, cloud hardware operators, and organizations using routers, IoT equipment, appliances, and server Baseboard Management Controllers, or BMCs, that rely on U-Boot in the boot chain.

What Binarly found in U-Boot

U-Boot uses Flattened Image Tree, or FIT, images to package boot components such as kernels, device trees, ramdisks, and signatures. The U-Boot FIT signature documentation explains that FIT signatures allow hashes to be signed with a private key and verified later with a public key.

The newly disclosed bugs target the parsing and validation steps around that process. In other words, a crafted image may trigger memory corruption, out-of-bounds reads, null pointer dereferences, or stack exhaustion while U-Boot is still checking whether the image should be trusted.

Binarly tracks the flaws as BRLY-2026-037 through BRLY-2026-042. Public advisories list U-Boot as the affected product and show disclosure dates of July 1, 2026.

Identifier	Main issue	Impact	Binarly severity
BRLY-2026-037	Null pointer dereference and possible stack buffer overflow in fdt_find_regions	DoS or possible code execution in some environments	Medium
BRLY-2026-038	Stack buffer underflow in fdt_find_regions	Bootloader code execution	Medium
BRLY-2026-039	Unchecked hashed-strings size value	Out-of-bounds read and DoS	Medium
BRLY-2026-040	Null pointer dereference in fdt_find_regions	DoS	Medium
BRLY-2026-041	Unchecked external data properties	Out-of-bounds read and DoS	Medium
BRLY-2026-042	Unbounded recursion in fdt_check_no_at	Stack exhaustion and DoS	Medium

Why the flaws matter before signature verification completes

Verified boot aims to stop unauthorized firmware or operating system images from loading. The problem here is that U-Boot still has to parse parts of the image before it can decide whether the signature is valid.

If parsing code trusts attacker-controlled lengths, offsets, node depth, or property values too early, a malicious image can crash the device or manipulate memory before the trust decision finishes.

The broader Binarly write-up frames the issue as a boot-chain risk because U-Boot runs before the main operating system and before many endpoint security tools can observe system behavior.

Two flaws can lead to code execution

The two most serious issues are BRLY-2026-037 and BRLY-2026-038. Both involve the fdt_find_regions function, which builds regions that feed into the signature hash process.

BRLY-2026-037 can cause a null pointer dereference and, in some cases, a stack-based buffer overflow if memory at address zero is mapped. That can turn a crash into code execution in specific bootloader environments.

BRLY-2026-038 is a stack buffer underflow caused by improper handling of length values. Binarly says exploitation can allow arbitrary code execution in the bootloader context.

Four flaws mainly cause denial of service

The remaining four vulnerabilities can crash the boot process by forcing U-Boot to read invalid memory, dereference invalid pointers, or exhaust stack space.

BRLY-2026-039 involves an unchecked size value in the hashed-strings property. A crafted FIT image can force excessive memory reads during hashing and trigger a DoS condition.

BRLY-2026-040 is another null pointer dereference in fdt_find_regions. Binarly describes it as reachable when processing older FDT versions during FIT signature verification.

BRLY-2026-041 comes from unchecked data-position, data-offset, and data-size properties for external image data. Attackers can make U-Boot hash data outside expected image boundaries.

BRLY-2026-042 abuses unbounded recursion in fdt_check_no_at. A deeply nested FIT structure can consume stack space until the bootloader crashes.

Remote exploitation depends on the update path

In many cases, an attacker would need a path to provide a malicious FIT image to the device. That may mean physical access, local administrative access, or control over a firmware update mechanism.

The risk grows when devices expose insecure management interfaces or accept firmware updates through weakly protected services. BMCs deserve particular attention because they often provide remote management for enterprise servers and can sit outside normal host operating system controls.

A successful attack could prevent a device from booting, interrupt recovery workflows, or place attacker code at an early stage of execution. Early boot compromise can also complicate detection because the malicious behavior may run below the operating system.

Patches have been submitted to U-Boot

Binarly coordinated with U-Boot maintainers and provided fixes. A U-Boot mailing list post from May 22, 2026 lists patches for all six issues.

The patch list includes return-value checks for fdt_get_name calls, bounds checks for the strings region, null pointer checks for fdt_get_property_by_offset, validation for external data bounds, and nesting-depth checks in fdt_check_no_at.

The patch summary also maps each fix to the relevant Binarly identifier, giving vendors a practical checklist for backporting fixes into maintained firmware branches.

What device makers and defenders should do

Organizations should not assume they are safe simply because they do not build U-Boot directly. Many products ship vendor forks, board support package versions, or long-lived firmware branches that can lag behind upstream fixes.

Teams should review firmware images, vendor advisories, and software bills of materials for U-Boot usage. The U-Boot documentation can also help engineering teams confirm where FIT signature verification sits in their boot process.

Recommended actions include:

1. Identify products and firmware builds that use U-Boot with FIT signature verification enabled.
2. Check whether the product uses upstream U-Boot, a vendor fork, or a board support package branch.
3. Apply an upstream release that contains the fixes or backport the relevant patches.
4. Review firmware update interfaces for authentication, authorization, and rollback protections.
5. Restrict BMC and device management interfaces to trusted networks.
6. Test recovery procedures for devices that could fail to boot after a malformed update.
7. Ask vendors for confirmation when firmware images contain U-Boot but no public security notice exists.

Firmware supply-chain exposure may last for years

U-Boot appears across a wide range of embedded and infrastructure devices. That broad adoption creates a long patch tail because vendors often maintain device-specific forks and may not ship firmware updates quickly.

The most exposed systems are those that allow remote firmware uploads, automated update pipelines, or management-plane access from networks that attackers can reach. Even when exploitation requires privileged access, these bugs can still help an attacker move from update control to early boot control.

The disclosure reinforces a familiar firmware security lesson: signature verification must validate untrusted structures before using their lengths, offsets, pointers, and recursion depth. Otherwise, the bootloader can fail before it gets the chance to reject a malicious image.

FAQ