Six U-Boot flaws trace to one libfdt helper
Binarly disclosed six bugs in U-Boot's FIT-image parsing on July 9 — two potential RCE, four DoS — all tracing to unchecked libfdt calls present since 2013.07.
Loop Binarly published six advisories on U-Boot on 2026-07-09, filed as BRLY-2026-037 through BRLY-2026-042. Two of the six may reach arbitrary code execution during boot. Four crash the device. All six sit in the same place: the code path that walks a Flattened Image Tree (FIT) container before U-Boot hands control to the kernel it contains.
The specific helper is fdt_get_name in libfdt — the flattened-device-tree
parsing library U-Boot links against, the same one the Linux kernel and
barebox link against. On a malformed FIT image, fdt_get_name returns a
null pointer and a negative length. The two code-execution bugs,
BRLY-2026-037 and BRLY-2026-038, are the callers that never check either
return. The pointer flows into pointer arithmetic that walks backward, or
into a copy sized by the negative length; the write lands on the boot
stack. That is enough, on affected paths, to overwrite a return address
before signature verification finishes.
The four denial-of-service bugs are the shape you would expect once you know the parser trusts its input. BRLY-2026-039 and BRLY-2026-041 read past the end of the image because they trust attacker-controlled size and offset values. BRLY-2026-040 dereferences a null pointer from an older image sub-format. BRLY-2026-042 recurses on deeply nested image structures until the stack is gone.
None of the six has a CVE assigned yet — Binarly’s own tracking IDs are what to search on until MITRE catches up.
The part that matters
The vulnerable code has been in U-Boot since v2013.07. That is more than fifty stable releases, sitting in every downstream that pulled a release from that range and never rebased. The Binarly writeup, Unfit to Boot, lays out the parser lineage. Upstream U-Boot has merged fixes; the next stable release carrying them is expected to be v2026.10 in October, per The Hacker News’s reporting on the disclosure. v2026.07, the release that shipped this month, does not include the fixes.
The distance between “upstream is patched” and “your device is patched” on U-Boot is the entire problem. U-Boot is not a product with a subscription; it is a code drop that vendors fork, patch for their own silicon, freeze, and forget. A home router shipped in 2019 with U-Boot 2018.03 is not going to get a 2026.10 backport. Neither is the baseboard management controller on a two-generation-old server. This is not a new observation — it is the same reason every U-Boot bug from the last ten years is still exploitable somewhere. The Binarly team, per BleepingComputer, frames the reach as “home routers, smart cameras, and the management chips inside data-center servers.” That reach is the point.
Reach vs. exploit path
Reach is not the same as trivial exploitation. Getting a malicious FIT image in front of the bootloader still requires a way to write to the boot medium — physical access, a privileged foothold in the running OS, or, as Binarly notes, a device-management channel that accepts firmware updates without properly authenticating them. Prior research they cite has walked exactly that last path on specific vendors; whether any given device is reachable that way depends on the device.
libfdt is the shared piece. The Binarly advisory notes the same helper lives in the Linux kernel and in barebox. The kernel copy is not called on the same untrusted input path — U-Boot’s job is to parse an image before it is trusted, which is why the bug matters in the bootloader and not, so far, in the kernel driver copy. Still: this is a library that a lot of low-level code shares. It rewards being audited.
What to do
If you build embedded products on U-Boot, the specific action is: pin your fork to a base that is either past v2026.10 when it lands, or carries the six Binarly-referenced patches backported by hand. Ask your silicon vendor which they are doing. If they cannot tell you, the answer is neither.
If you operate devices in the field, there is nothing you can do at the bootloader layer without a firmware update from the vendor. What you can do is stop trusting the update channel to authenticate itself: gate firmware pushes behind out-of-band controls, and treat the device management network as its own trust boundary. That advice predates these six bugs by a decade, and it will still be true after the next six.
The physical layer is patient. It has been running the same code path since 2013.
Found this useful? Share it.
