U-Boot’s verified boot checks a FIT image’s signature before it trusts the image. Six flaws disclosed in July 2026 all live in the code that runs before that check finishes — the parser that reads the untrusted image. Two of them can lead to code execution during verification and four can crash the device, and the two worst both come from a single unchecked return value from one shared device-tree helper. The patches are upstream, but for a product already in the field that is only the first step: you first have to establish whether the vulnerable path is even reachable in your build, then move the fix through your SoC vendor’s fork, your build, a re-signed image, and a bootloader update that many devices were never designed to accept safely.
Verified boot is meant to guarantee one thing: a device only runs software that has been signed by a key you control. On many embedded Linux systems, U-Boot provides that guarantee for the kernel, device tree and ramdisk it loads. In July 2026 a set of vulnerabilities was disclosed in exactly the U-Boot code that implements this guarantee. It is worth understanding in detail, because the flaw is not a weak signature algorithm or a leaked key. It is something more ordinary and more instructive: the image parser that runs before the signature is verified trusted data it should not have.
What U-Boot verified boot actually promises
U-Boot can package a kernel, device tree, ramdisk and other boot components into a single container called a FIT image (Flattened Image Tree). A FIT is itself a flattened device tree: a tree of nodes and properties, the same binary format the kernel uses to describe hardware. Inside the FIT, a configuration node lists which images make up a bootable set, and a signature node holds a cryptographic signature over that configuration.
When verified boot is enabled, U-Boot is built with a public key. Before it boots a configuration, it hashes the images the configuration references, checks the signature against its built-in key, and refuses to continue if the check fails. That is the root of trust: the first stage that runs is trusted because it is in read-only storage or on-chip ROM, and everything after it is trusted only because this signature check passed.
The important word is before. To find the signature node, to know which bytes to hash, and to walk the configuration, U-Boot must first parse the FIT. That parsing happens on an image that has not yet been verified. If the image is malicious, every line of parser code that runs before the signature check is part of the attack surface.
The flaw class: parse before verify
This is the pattern worth remembering, because it recurs across firmware security. The verification step is cryptographically sound. The problem is that a real implementation cannot verify raw bytes; it has to interpret them first — find fields, read lengths, follow offsets — and that interpretation is code running on attacker-controlled input with the trust decision not yet made.
Two earlier, well-known cases followed the same shape. LogoFAIL in 2023 was a set of image-parsing bugs in PC firmware: the code that decoded a boot logo ran before Secure Boot could check anything, so a malicious logo could run code. BootHole in 2020 was a parsing flaw in GRUB2’s configuration handling that broke the Secure Boot chain. In each case the signature scheme was fine; the parser in front of it was not. The U-Boot FIT flaws are the same class of problem in the embedded bootloader that most Linux devices actually use.
The single mistake behind the two worst bugs
The two flaws that can lead to code execution both trace to one unchecked return value. When U-Boot works out which regions of the FIT the signature is supposed to cover, it calls fdt_get_name(), a lookup in libfdt — the flattened-device-tree library U-Boot shares with the Linux kernel and the barebox bootloader. On a well-formed tree, fdt_get_name() returns a pointer to a node’s name and writes its length through an output parameter. On a malformed node, it can instead return a NULL pointer and a negative length. The calling code in the region-collection routine used both results without checking either.
The shape of the mistake is easy to state without any exploit detail. The vulnerable pattern is this:
/* Vulnerable pattern: the return value is used unchecked. */
int len;
const char *name = fdt_get_name(fit, node_offset, &len);
/* On a crafted image, name can be NULL and len can be negative.
* Both are used directly below without validation. */
memcpy(dst, name, len); /* NULL source, or a length that is wrong */One of the two bugs follows the NULL pointer into a memory copy, which on hardware where address zero is a valid mapping becomes an overflow on the stack. The other feeds the negative length into pointer arithmetic that then walks backwards through memory far enough to reach a saved return address. Neither requires exotic conditions to crash; whether either reaches full code execution depends on the memory layout of the specific device — the code-execution outcome is conditional, not guaranteed. The correct fix is the boring one that should have been there from the start:
/* Correct pattern: validate before use. */
int len;
const char *name = fdt_get_name(fit, node_offset, &len);
if (!name || len < 0)
return -EINVAL; /* reject the image, do not parse further */
memcpy(dst, name, len);Because fdt_get_name() comes from libfdt, which is used far beyond U-Boot, the same unchecked-return mistake can exist anywhere that helper is called on untrusted input. That is the part of this disclosure with the longest reach.
The four denial-of-service bugs
The other four flaws crash the bootloader rather than running code, and they share a single theme: the parser trusted a size, an offset or a nesting depth that the attacker controls. Grouped that way they are easy to hold in mind.
| Advisory | Effect | Root cause |
|---|---|---|
| BRLY-2026-037 | Possible code execution | NULL pointer from fdt_get_name() followed into a copy on the stack. |
| BRLY-2026-038 | Possible code execution | Negative length from fdt_get_name() drives pointer arithmetic backwards in fdt_find_regions(). |
| BRLY-2026-039 | Denial of service | Unchecked size of the hashed-strings property leads to an out-of-bounds read. |
| BRLY-2026-040 | Denial of service | NULL dereference when fdt_get_property_by_offset() returns NULL for an older FDT version. |
| BRLY-2026-041 | Denial of service | External-data properties (offset and size) point outside the image bounds and are trusted. |
| BRLY-2026-042 | Denial of service | Unbounded recursion in fdt_check_no_at() exhausts the stack on a deeply nested tree. |
A crash at boot is not harmless. On a device that will not boot, recovery often means physical access and reflashing the storage with a clean image, which for a fleet in the field is expensive. But the two memory-corruption bugs are the ones to prioritise, because code that runs this early sits below the operating system, where the security tools that run later cannot see it.
How an attacker actually reaches this
One qualification matters before anyone treats this as an emergency. All six flaws require a malicious FIT image to reach the boot or verification path in the first place. In practice that means one of two things: physical access to the device, or an already-compromised update channel — for example a server management controller (BMC) that accepts remote firmware uploads, where an attacker who already holds the management interface can supply a crafted image without touching the hardware. This is not a remote, unauthenticated drive-by. That precondition should govern how urgently you rank this against your other exposure: a device that only ever loads a FIT from internal, signed-at-build storage is in a very different position from one that accepts externally supplied images over a network path.
Why this reaches so far
Most of the vulnerable code has been present since U-Boot v2013.07. That is more than fifty stable releases, and it is also present in the many vendor firmware images built on top of U-Boot for routers, cameras, industrial controllers and server management chips. The code is old, widely copied, and sits at the most trusted point in the boot chain.
There is a recent precedent in the same subsystem. In April 2026, CVE-2026-33243 fixed a different weakness in the same FIT signature logic: a property that listed which parts of the image the signature covered was not itself signed, so a tampered image could substitute components that were never verified. The related barebox bootloader, which uses the same image tooling, was affected as well. The signature check keeps drawing attention to the plumbing around it. Note that this earlier CVE is a distinct issue from the six advisories here — do not conflate them when you brief your team.
The fix is upstream. Your device is not.
Most coverage of a disclosure like this ends at the sentence “patches have been accepted upstream.” For anyone maintaining a product that is already designed, certified and shipping, that sentence is where the work begins, not where it ends. It is worth being precise about what still stands between the upstream commit and a device in a customer’s hands.
First, work out whether the vulnerable path is even reachable
Before anyone backports anything, answer a smaller question: does the vulnerable code run in your product at all, and on input an attacker can influence? This is the step every other writeup skips, and it is the one that decides how much of the rest matters. Concretely:
- Is FIT signature verification actually compiled in? Check whether
CONFIG_FIT_SIGNATUREis set in your U-Boot configuration, and — separately — whetherCONFIG_SPL_FIT_SIGNATUREis set, because many products do the verification in the SPL (the small first-stage U-Boot), not in full U-Boot. The SPL is a size-constrained, separately built binary; a fix that is trivial in full U-Boot still has to fit the SPL’s memory budget, so confirm both builds. - Does your device parse a FIT it did not produce? If the only FIT it ever sees is the one you signed at build time and wrote to internal storage, the attacker-controlled-input premise is weaker. If it accepts a FIT over an update channel, a recovery path, or removable media, the premise holds and you are squarely in scope.
- Is the parse reachable after manufacturing? A one-time provisioning path that is fused off in production is different from a runtime update path that stays open for the life of the device.
If the answer to all three is that no untrusted FIT ever reaches the parser, your exposure is genuinely low and you can schedule the fix rather than scramble. If any is a yes, continue.
The patch has four hops, not one
The fix has to travel: from mainline U-Boot, into your SoC vendor’s U-Boot fork, into your BSP and build, into a signed firmware image, and finally onto a device that is already deployed. The disclosure completed the first hop. Every remaining hop belongs to someone else, and each one has its own schedule.
Backporting is usually easy; getting someone to own it is not
The standard advice — pull the upstream commits — is sound, and for these particular fixes the diffs are small, self-contained checks in the FIT and libfdt code. The mechanical risk of a backport is low. The real friction is elsewhere. Most products build from a silicon vendor’s fork pinned to an older base, and on such a tree the surrounding region-collection code may predate later refactors, so the patch may need adapting to the version you actually run. More to the point, on a vendor fork nobody on your team may be assigned to do that work at all — it waits on the vendor. The blocker is ownership and cadence, not whether the diff applies.
The bootloader is the riskiest thing to update in the field
This is the part that is easy to miss until you attempt it. Many products are designed with redundancy for the kernel and root filesystem — an A/B scheme, a fallback slot, a recovery image — but carry a single, non-redundant bootloader. Not all: some designs do keep a redundant bootloader slot or fall back to a recovery loader in ROM or SPL. But where the bootloader is single, a kernel update that fails can roll back, while a bootloader update that fails is a device that does not start, and recovery means physical access and a reflash — exactly the outcome the denial-of-service bugs would have produced anyway.
So the honest question a team has to answer is not “can we build a fixed U-Boot?” but “can we safely replace U-Boot on a device that is already in a customer’s hands?” If the answer is no, then this entire class of bootloader vulnerability is unfixable in your fleet, and that is worth discovering now rather than during the next disclosure.
Re-signing and anti-rollback set the real constraints
Shipping a fixed bootloader means re-signing it, and it is worth separating two hardware facts that are often blurred together. A fuse-locked key hash — NXP HABv4 or AHAB, TI’s secure boot, ST’s OTP-provisioned keys — constrains which key is allowed to sign. It does not stop you shipping a fix: you re-sign the corrected bootloader with the same production key, and the device accepts it. What genuinely limits you is a monotonic anti-rollback counter, often backed by one-time-programmable fuses. Bumping the version to shut out the vulnerable image means burning a fuse or incrementing a hardware counter, which is irreversible and available only a finite number of times. That is the constraint that was fixed at manufacturing, and it is the one to check before you plan a versioned rollout.
For most teams the real action is vendor pressure — with specifics
If you consume a vendor BSP rather than maintaining your own U-Boot tree, the practical move once you have confirmed reachability is to press the vendor precisely. Ask, in writing, when they will rebase or backport these six fixes into the release you build from, and ask which advisories they are taking — a vendor that quietly picks up only the two code-execution fixes and leaves the four denial-of-service ones is a common and unwelcome outcome. Get a date, plan your firmware release around it, and keep the correspondence. Under the Cyber Resilience Act you may have to show that you asked.
There is no CVE — you still owe your customers a statement
Because no CVE identifiers have been assigned, you cannot point a customer at a National Vulnerability Database entry, and a customer’s own scanner will not flag this against your product. That does not remove your obligation to say something. Reference the Binarly advisory IDs (BRLY-2026-037 through 042) and the upstream commits directly in your product security advisory, state which of your products are affected and your remediation timeline, and treat the absence of a CVE as a communication problem to solve rather than a reason to stay silent. For products on the EU market, the Cyber Resilience Act’s duties around known and exploited vulnerabilities apply regardless of whether a CVE exists.
The Cyber Resilience Act changes the stakes
Until recently, “we have no way to update the bootloader in the field” was an engineering embarrassment. For products placed on the EU market it is becoming a compliance problem. The CRA requires manufacturers to handle vulnerabilities in their products and their components and to provide security updates through the support period; an architecture that structurally cannot deliver a bootloader fix does not meet that bar. We set out those obligations in our guide to CVEs and the Cyber Resilience Act.
The wider point is this: a disclosure like this one is a test of your update architecture, not only of your U-Boot version. The teams that will ship a fix in weeks are the ones who designed a safe bootloader-update path years ago, before they knew what they would need it for.
What a device vendor should do now
- Confirm reachability first. Check
CONFIG_FIT_SIGNATUREandCONFIG_SPL_FIT_SIGNATURE, and whether your device ever parses a FIT it did not sign at build time. This decides whether the rest is urgent or scheduled. - Inventory what you ship. Identify the U-Boot version in each product, including the versions inside vendor BSPs and reference firmware. A software bill of materials makes this a lookup rather than an investigation.
- Press the silicon vendor with specifics. Ask when the fixes land in your branch and which of the six advisories they are taking, and get a date in writing.
- Backport now if you own the tree. Do not wait for v2026.10 in October. Pull the fixes, following the commit links in each Binarly advisory, and track them by advisory ID because there are no CVE identifiers to watch yet.
- Test the bootloader update path itself. Before you need it in an emergency, confirm you can replace U-Boot on a fielded device and recover from a failed attempt, and confirm your anti-rollback budget allows a version bump. If you cannot, that is the finding, and it outranks the CVE.
- Consider reproducing the method. Binarly found these by fuzzing the FIT parse path on the U-Boot
sandboxbuild. Pointing a fuzzer at the same entry points on your own fork is the way to find the ones specific to your patches, rather than waiting for the next external disclosure. - Publish an advisory even without a CVE. Cite the BRLY IDs and commits, name affected products, and give a remediation date.
The engineering takeaway
The durable lesson is not “patch U-Boot”, though you should. It is that a root of trust has a boundary, and the boundary is not where the signature is checked — it is where the first byte of untrusted input is read. Every function that touches the image before verification completes is inside the trust boundary, and every value it reads from that image, including the return values of library helpers, has to be validated as hostile input. Bootloader bring-up, FIT images, secure boot and a workable field-update design are core board-support work, and defensive parsing of untrusted device-tree and FIT data is a specific, teachable part of it. It is the ground our Embedded Linux on Edge AI track covers, where the boot chain and its security are treated as one subject rather than two.
Key takeaways
- U-Boot’s verified boot signs and checks a FIT image, but the parser that reads the image runs before the signature check completes, so it operates on untrusted input.
- Six flaws (BRLY-2026-037 to BRLY-2026-042) live in that pre-verification parser: two may allow code execution (conditionally), four cause denial of service. No CVEs are assigned yet.
- Before backporting, confirm the path is reachable: is
CONFIG_FIT_SIGNATUREorCONFIG_SPL_FIT_SIGNATUREset, and does the device ever parse a FIT it did not sign? - The two code-execution bugs both come from using the return value of
fdt_get_name()— a NULL pointer and a negative length — without checking it. - For a shipping product the upstream patch is only the first of four hops; the blocker is usually vendor ownership and cadence, and a safe bootloader-update path, not the diff itself.
- Re-signing is fine with a fuse-locked key; the real limit is the anti-rollback counter, which is one-way and finite.
- There is no CVE, so publish an advisory citing the BRLY IDs and commits — your customers’ scanners will not flag this for you.
Frequently asked questions
How do I tell whether my product is affected?
Check whether FIT signature verification is compiled in — CONFIG_FIT_SIGNATURE for full U-Boot and CONFIG_SPL_FIT_SIGNATURE for the SPL — and whether your device ever parses a FIT image it did not produce and sign itself, for example over an update channel or removable media. If an untrusted FIT can reach the parser, you are in scope; if the only FIT it loads is your build-time-signed image from internal storage, exposure is lower.
Does verified boot being enabled protect me from these flaws?
No. All six flaws are reached while U-Boot is parsing the FIT image, before the signature check completes. Enabling verified boot does not move the parser after the check — the parser is what feeds the check — so a malicious image can trigger the bugs regardless of whether verification is turned on.
My product uses my SoC vendor’s U-Boot fork, not mainline. What do I do?
Ask the vendor in writing when they will rebase or backport the fixes into the branch you build from, and ask which of the six advisories they are taking, since a vendor may pick up only the code-execution fixes. The diffs are small, but on an older fork the surrounding code may need the patch adapted, and if you do not own the tree the work waits on the vendor.
Are there CVE numbers for these vulnerabilities?
Not at the time of the disclosure. They are tracked as Binarly advisories BRLY-2026-037 through BRLY-2026-042. Because there are no CVEs to follow, track the fixes by advisory ID and by the upstream commit links, and cite those IDs in any advisory you publish to your own customers.
Can I even ship a fixed bootloader on a fuse-locked device?
Usually yes. A fuse-locked key hash only constrains which key may sign, so you re-sign the corrected bootloader with the same production key. The harder limit is a monotonic anti-rollback counter: bumping the version to lock out the vulnerable image may require burning a fuse or incrementing a hardware counter, which is irreversible and finite, so plan the version step deliberately.
Further reading
- Binarly — Unfit to Boot: Breaking U-Boot’s FIT Signature Verification and the Binarly advisories (BRLY-2026-037 to 042)
- The Hacker News — Six New U-Boot Flaws Could Let Malicious Images Crash Devices or Run Code at Boot
- BleepingComputer — New U-Boot flaws could enable stealthy firmware attacks
- U-Boot documentation — FIT signature verification
- U-Boot commit for the related, earlier CVE-2026-33243 (April 2026)
- TECH VEDA — What Is a CVE, and What Is the Cyber Resilience Act?
