Kernel & Embedded News: Six U-Boot Verified Boot Flaws Disclosed

Six U-Boot FIT verification flaws, the kernel crypto library API, LLM-assisted memory-management patches under review, and a narrower Yocto LTS list.

This edition is mostly about trust and maintenance. One item concerns the code that decides whether your device should trust the image it is about to boot; the others concern how kernel code is written, reviewed, and supported over the life of a product.

In this edition

• Six flaws found in U-Boot’s FIT signature verification. Binarly’s research team disclosed six issues in the code that validates signed FIT images — two of them potentially allowing arbitrary code execution before the operating system starts (report).
• Kernel cryptography is moving to a library API. Eric Biggers described at the 2026 Linux Security Summit North America how new library functions let kernel code compute hashes and ciphers without the traditional crypto API’s allocation and error-handling boilerplate (LWN).
• Two LLM-assisted memory-management patch sets are under review. Established developers submitted large patch sets produced with LLM assistance, and the response differs from how the community has treated similar submissions from unknown contributors (LWN).
• The Yocto Project’s supported release list is down to two LTS branches. Whinlatter (5.3) and Walnascar (5.2) are now marked end of life; only Scarthgap (5.0) and Wrynose (6.0) remain under long-term support (release table).

Six flaws in U-Boot’s FIT signature verification

Binarly published research on 10 July 2026 describing six previously unknown vulnerabilities in U-Boot’s FIT (Flattened Image Tree) signature verification path, the code that underpins Verified Boot. The issues are tracked as BRLY-2026-037 through BRLY-2026-042. Two can potentially lead to arbitrary code execution during verification; the other four cause crashes through out-of-bounds reads, a null pointer dereference, unchecked external data offsets, and unbounded recursion that exhausts the stack.

The important detail is when the flaws trigger. They are reachable while U-Boot is parsing and verifying an untrusted image — that is, before the signature check has succeeded. A malicious image does not have to be validly signed to do damage.

Most of the affected code has been present since U-Boot 2013.07, so more than fifty upstream releases and a large number of vendor forks inherit it. This includes BMCs, routers, industrial gateways, and set-top boxes. Binarly notes that physical access is not always required: on a BMC that accepts remote firmware updates, an attacker who already controls the management interface can supply a crafted image.

Binarly reported the issues to the U-Boot maintainers and submitted patches, which have been accepted upstream. That does not close the matter for product teams. U-Boot reaches devices through vendor BSPs, so the fixes must travel from mainline into your SoC vendor’s U-Boot fork, then into your build, then into a signed firmware update.

My advice is to treat this as a firmware release task and start it now. Identify which U-Boot version your product is built from, confirm with your SoC vendor when they will rebase or backport these fixes, and plan a firmware update for fielded devices. Where remote firmware upload is exposed on a management interface, restrict that path until the fix ships.

There is a wider point about verified boot. A signature check is only as trustworthy as the parser in front of it, and this disclosure shows that the parser itself is attack surface. If your threat model assumes verified boot cannot be bypassed, that assumption needs supporting evidence: fuzzing of the image-parsing path, and a documented plan for updating the bootloader in the field.

Kernel cryptography moves towards a library API

At the 2026 Linux Security Summit North America, Eric Biggers presented the problems with the kernel’s traditional crypto API and the progress made in offering library APIs instead, as reported by LWN on 8 July. The old API requires callers to allocate a transform, set up a request structure, handle asynchronous completion, and check errors at several points, even when all they want is a hash of a buffer in memory.

The library approach replaces that with plain function calls. Computing a SHA-256 digest becomes a single call rather than a sequence of allocations that can each fail.

For driver and subsystem authors this reduces a common source of bugs. Much of the error handling in crypto call sites exists only because the API can fail in ways that a straightforward hash computation never should, and code that is rarely exercised is code that is rarely correct.

If you maintain out-of-tree drivers or a vendor kernel that uses the old crypto API for simple hashing, plan to move those call sites as you rebase. The change is mechanical and it removes error paths rather than adding them. Where you use hardware crypto accelerators, the traditional API remains the right interface — the library functions are aimed at the synchronous, in-memory cases that make up most kernel usage.

Two LLM-assisted memory-management patch sets under review

LWN reported on 2 July that memory-management developers are evaluating two large patch sets developed with LLM assistance and submitted by established, well-regarded contributors. The kernel community has been receiving a growing volume of LLM-assisted patches, but those have mostly come from people the maintainers do not know. The difference in reception here is instructive.

What is being weighed is not the tool but the accountability behind the submission. A known developer who has read, tested, and understood the generated code, and who will answer for it when it breaks, is a different proposition from an unknown sender posting output they cannot explain.

Teams inside product companies are facing the same question in their own review queues. The workable position is that a patch carries the author’s name and the author’s understanding, whatever tool produced the first draft. If an engineer cannot explain why a change is correct, the change is not ready for review, and no amount of tooling changes that.

This is also a hiring and training signal. The scarce skill is not producing code; it is reading kernel code well enough to judge whether a change is safe. That judgement is what our kernel internals training is built around, and it is becoming more valuable, not less.

Yocto’s supported release list narrows to two LTS branches

The Yocto Project’s release table now lists Whinlatter (5.3, December 2025) and Walnascar (5.2, May 2025) as end of life. The supported long-term branches are Scarthgap (5.0), maintained until April 2028, and Wrynose (6.0), released in April 2026 and maintained until April 2030. Blacksail (6.1) is due in October 2026 with a six-month support window.

The pattern is unchanged but worth restating: non-LTS Yocto releases receive roughly six months of updates. If a product’s BSP is pinned to a non-LTS branch, CVE fixes in recipes stop arriving well before the product ships in volume.

For any device with a multi-year field life, build on an LTS branch. New designs starting now should target Wrynose (6.0), which carries support to April 2030 and gives a realistic runway for a product entering production in 2027. Scarthgap remains a reasonable base for designs already in progress, but April 2028 is closer than it appears once certification and field deployment are accounted for.

If you are currently on Whinlatter or Walnascar, schedule the migration rather than deferring it. Under the EU Cyber Resilience Act, being unable to supply security updates for a connected product is a compliance problem, not only an engineering inconvenience.

References

• New U-Boot flaws could enable stealthy firmware attacks — BleepingComputer
• Unfit to Boot: Breaking U-Boot’s FIT Signature Verification — Binarly
• U-Boot documentation: Verified Boot
• Progress in modernizing kernel cryptography — LWN.net
• Two LLM-assisted memory-management patch sets — LWN.net
• Yocto Project releases and support levels
• Yocto Project: Releases

— Raghu Bharadwaj