U-Boot

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Separately, for a merged upstream patch : up to $5,000 Google Patch Rewards pays for a patch you land upstream yourself and that stays merged, without reverts, for one month, not for the report. This project sits in Tier 2, where awards run from $100 to $5,000; the $15,000 headline is the Tier 1 column and is not reachable here. Patches must be between one and twelve months old, submissions are capped at three per person per month, memory-safety hardening can carry a 2× or 3× multiplier, and sanctions and territory exclusions apply. CVE history 7 Last 12 months 50 Lifetime Memory safety 40 % Parsing/validation 30 % Auth bypass 15 % Info disclosure 10 % Latest advisories Loading the feed Overview U-Boot is the bootloader on essentially every non-x86 embedded Linux device: ARM and RISC-V single-board computers, consumer routers and NAS boxes, set-top boxes, industrial gateways and a large share of automotive infotainment. It is also the boot layer baked into Yocto, Buildroot, OpenWrt and Armbian images. Its verified-boot implementation is the enforcement point for secure boot on those platforms, so a parsing bug here is usually a secure-boot bypass: code that runs before the kernel, survives reinstalls and is very hard to fix in the field. The project pays nothing for a report and says it cannot enter non-disclosure agreements, so sorona.xyz pays you directly on qualified, reproduced findings. In scope U-Boot takes security reports through the process in its SECURITY.md and, in practice, on the project mailing list. The covered object is the upstream u-boot/u-boot tree in full, and no boundary narrower than that tree is drawn anywhere The boot image path end to end: the FIT and legacy uImage parsers, and the verified-boot signature checking built on top of them Every storage path U-Boot reads before OS handoff, covering the ext4, FAT, SquashFS and UBIFS filesystem drivers, the GPT, MBR and DOS partition-table parsers, and the MMC, USB and NVMe block layers beneath them The whole network stack and every boot protocol running on it: DHCP, TFTP, NFS, PXE and the newer HTTP/wget boot path, all reachable from the local network before any OS is running The EFI loader subsystem, which reimplements a large UEFI surface inside U-Boot Environment-variable handling and the command-line interpreter reachable over serial, where bootcmd and bootargs decide what actually boots Out of scope Board-specific and silicon-vendor forks; only merges into upstream u-boot/u-boot count Defects that exist only in a distribution's packaging of U-Boot (Yocto, Buildroot, OpenWrt, Armbian) and not in the upstream tree Non-exploitable crashes whose fix is a one-liner, which Google explicitly declines to reward on the patch rail Patches over twelve months old, which Patch Rewards will not consider For the Google money specifically, anything reported but never patched upstream, since that pathway pays only on a merge Most-valued findings A verified-boot bypass: anything in FIT image parsing or signature checking that lets an unsigned or altered payload boot, since that defeats the guarantee the whole subsystem exists to provide Memory corruption in the pre-OS network path, covering DHCP, TFTP, PXE and the HTTP boot client, all remotely reachable on the local network before any kernel, mitigation or logging exists Filesystem or partition-table parsing bugs reached from removable media or a recovery partition, the classic path for an attacker with brief physical access Flaws in the EFI loader subsystem, where U-Boot reimplements UEFI semantics and inherits that surface without the scrutiny the reference implementation gets Environment or command-interpreter handling that lets attacker-supplied data alter bootcmd or bootargs and so achieve persistence across reflashes Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Send a detailed, reproducible report with the image, boot payload or command sequence that triggers it, and name the board or QEMU target you reproduced on One vulnerability per report unless a chain is needed to show the real impact Only upstream u-boot/u-boot counts. Board-specific vendor forks are not this target, and a fix has to land upstream U-Boot states it is unable to enter non-disclosure agreements, so plan for a mailing-list coordinated fix rather than a private embargo If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for a month. The patch must be between one and twelve months old and you may submit at most three a month Google cannot pay researchers on sanctions lists, in sanctioned territories, or located in Russia or Belarus Disclosure Coordinated through the process in the repository's SECURITY.md and, in practice, on the U-Boot mailing list; the project does not use GitHub Security Advisories and says it is unable to enter non-disclosure agreements, so treat the fix as becoming public when the patch is posted. Nothing in the Google rules restricts routing the finding through sorona.xyz. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability