Six New U-Boot Flaws Risk Device Crashes and Unauthorized Code Execution at Boot
Researchers from the firmware security firm Binarly have identified six critical vulnerabilities in U-Boot, the bootloader responsible for initializing a wide array of hardware, including home routers, smart cameras, and data center management chips. These flaws present significant risks, with four capable of crashing devices and two potentially allowing attackers to execute arbitrary code before the software’s authenticity is verified.
The implications of these vulnerabilities are profound. Since the bootloader operates prior to the operating system, any weaknesses at this stage can compromise the integrity of all subsequent software. All six vulnerabilities can be exploited while U-Boot processes an untrusted image, prior to signature verification.
Insights from Binarly’s Findings
U-Boot is designed to package various boot components—such as the kernel, device tree, and ramdisk—into a single entity known as a Flattened Image Tree (FIT). This package undergoes a digital signature check before control is transferred to the operating system.
Binarly’s investigation into the signature verification process revealed six vulnerabilities, most of which have persisted since U-Boot version 2013.07. These flaws have been present across more than 50 stable releases and are also found in numerous vendor-specific firmware implementations built on U-Boot.
The vulnerabilities are cataloged as Binarly advisories BRLY-2026-037 through BRLY-2026-042, with no Common Vulnerabilities and Exposures (CVE) identifiers assigned to them at this time. They can be divided into two categories: two that allow code execution and four that result in device crashes.
The two vulnerabilities allowing code execution, BRLY-2026-037 and BRLY-2026-038, stem from an unchecked value. U-Boot utilizes the function fdt_get_name from its device-tree parsing library. When processing a malformed image, this function can return a null pointer and a negative length, both of which are used without validation.
One vulnerability leads to a stack buffer overflow due to a null pointer dereference, while the other exploits negative length in pointer arithmetic, potentially overwriting a saved return address. In specific memory layouts, either could enable an attacker to gain control.
The remaining four vulnerabilities lead only to crashes. BRLY-2026-039 and BRLY-2026-041 read beyond the image’s end by trusting attacker-controlled sizes or offsets. BRLY-2026-040 dereferences a null pointer returned unchecked from an older image format. BRLY-2026-042 exhausts the stack due to a deeply nested image that triggers recursive validation calls until the stack is depleted.
Binarly has released proof-of-concept images and reproduction steps for each flaw, demonstrating their impact on standard U-Boot builds. As of now, no real-world exploitation has been reported.
Severity of the Vulnerabilities
The most severe risks arise from the two memory corruption vulnerabilities. While a crash can render a device inoperable, the ability to execute code during the boot process poses a far greater threat, as it can undermine the entire chain of trust within the device.
In extreme cases, recovering a device that fails to boot may require physical access and reflashing its memory chip with a clean image. The risk of code execution is particularly concerning, as it occurs below the operating system level, where conventional security measures may not detect it.
However, the challenge for attackers lies in the delivery mechanism. These vulnerabilities can only be exploited if a malicious image is introduced into the boot path, typically necessitating physical access or a privileged foothold. Such a foothold is not always local.
In prior research on Supermicro’s server management controllers, a Binarly researcher demonstrated that an attacker with remote access to the management interface could exploit the device’s update process to flash a malicious image without physical interaction.
Recommended Actions for Mitigation
Currently, there is no stable release containing fixes for these vulnerabilities. Vendors and maintainers of U-Boot-based products are urged to take immediate action by integrating the upstream fixes available in the Binarly advisories. Tracking these advisories is crucial, as no CVEs have been assigned.
Although U-Boot merged the six patches in June, the July release (v2026.07) had already been frozen in April, resulting in the absence of these fixes. The next scheduled release, v2026.10, is not expected until October.
For users operating devices built on U-Boot, the necessary fixes will come as firmware updates from the respective product vendors. Monitoring for these updates is essential.
This particular signature check has previously failed. A related vulnerability, CVE-2026-33243, was patched in April. This flaw involved a property intended to list what the signature covers but was not itself signed, allowing tampered images to replace unverified components. The function fdt_get_name, which underpins the two most critical vulnerabilities, is derived from the libfdt library shared with the Linux kernel and other systems. This unchecked-return issue could manifest in various contexts where the code is utilized.
Similar vulnerabilities have emerged in the past. For instance, the LogoFAIL vulnerabilities identified in 2023 allowed attacker code to execute during the boot process across numerous major PC brands, before Secure Boot could validate anything. The focus often remains on the signature; however, the underlying vulnerabilities continue to infiltrate the foundational layers of system security.
The BootHole incident in 2020 illustrated how a single bootloader flaw could compromise Secure Boot across an entire ecosystem. While developing a patch is relatively straightforward, the challenge lies in deploying it across millions of devices utilizing U-Boot.
Source: thehackernews.com
Keep reading for the latest cybersecurity developments, threat intelligence and breaking updates from across the Middle East.
