security findings in U-Boot network stack, squashfs, and fastboot (follow-up)

[Vito Rallo]

Dear security group,

Copying the mailing list, as I read from the "handling security"
instructions, at the link pointed by Tom. I reported a vulnerability,
validated with PoC included, NFS store_block
unbounded write which I preferred to send directly to Tom with all the
confidential info instead of public mailing list.

The vuln research and scan has been performed with an enhanced version of
Foil, an AI security code scanner that runs on local LLM.
http://foil.peachstudio.be. (C/C++ version of the model not publicly
available yet).

Foil uses a trained model to identify security vulns, the original version
uses a model tuned on traditional web/app related vulns. I have been
developing and re-train an additional new model optimised for C code (which
has different vulns than traditional modern languages like TS, JS, Python
and all the frameworks in that jazz).

During the same automated scan of
U-Boot v2026.07-rc1, four additional security issues were identified.
I'm reporting them together for coordinated disclosure.

## Finding 2: squashfs sqfs_read_entry heap over-read (HIGH)

fs/squashfs/sqfs.c, line 238. The sqfs_read_entry() function reads
name_size (u16) from a squashfs directory entry and uses it as a
memcpy length without bounds checking. A crafted squashfs image can
set name_size to 65535, causing a 64KB over-read from an 8KB
metadata buffer.

The vulnerability was introduced in commit c5100613037 (July 30,
2020) when squashfs support was added — nearly 6 years ago. This is
the same bug class as the Trail of Bits fix in commit e365a269df5
(Feb 2026) for sqfs_frag_lookup(). Trail of Bits found and fixed
that instance via fuzzing but missed sqfs_read_entry() in the same
file, 60 lines away.

PoC confirmed: a crafted squashfs image with name_size=0xFFFF
causes a 61KB heap over-read when U-Boot lists the directory.
Tested in QEMU ARM with U-Boot v2026.07-rc1.

Full report will be sent to Tom: vuln-report-squashfs-read-entry.md

## Finding 3: TFTP store_block integer overflow (HIGH)

net/tftp.c, line 161. The block number from TFTP DATA packets is
multiplied by tftp_block_size to compute the write offset. On
32-bit platforms, this multiplication overflows at high block
numbers, wrapping the write address. The lmb_read_check() guard
only fires when CONFIG_IS_ENABLED(LMB), which many embedded
targets don't enable.

Full report will be sent to Tom: vuln-report-tftp-integer-overflow.md

## Finding 4: wget strcpy with network data (MEDIUM)

net/wget.c, line 158. HTTP response headers are copied using
strcpy() instead of strlcpy(). The size is validated before the
copy, but the use of a null-terminated copy function means edge
cases in TCP reassembly could cause the validation and the copy
to diverge.

Full report will be sent to Tom: vuln-report-wget-strcpy.md

## Finding 5: fastboot ucmd unauthenticated command execution (HIGH)

drivers/fastboot/fb_command.c, line 397. The fastboot "oem ucmd"
and "oem acmd" commands pass user-supplied strings directly to
run_command() without authentication, authorization, or input
validation. An attacker with USB access to a device in fastboot
mode can execute arbitrary U-Boot commands, modify the boot
environment, and install a persistent backdoor.

This is a dangerous default configuration rather than a code bug.
Android's fastboot gates OEM commands behind bootloader unlock
state. Looks to me that U-Boot's implementation has no equivalent gating.

Full report will be sent to Tom: vuln-report-fastboot-ucmd.md

## Summary table

| # | Component | Severity | CWE | Type |
|---|-----------|----------|-----|------|
| 1 | NFS store_block (previously reported) | Critical (9.6) | CWE-120 |
Unbounded write |
| 2 | squashfs sqfs_read_entry | High (7.8) | CWE-125 | Heap over-read |
| 3 | TFTP store_block | High (8.1) | CWE-190 | Integer overflow |
| 4 | wget strcpy | Medium (6.5) | CWE-120 | Unbounded copy |
| 5 | fastboot ucmd | High (7.6) | CWE-78 | Unauthenticated cmd exec |

I will file CVE request for 1 and 2. Let me know if you believe the other 3
are good candidates for a CVE too.

## Discovery method

All findings were discovered using foil, an AI-powered security
code scanner, with a fine-tuned 7B parameter model trained on
C/C++ vulnerability patterns. The scan of U-Boot's network stack
(375 functions) took 10 minutes and produced 28 raw findings,
of which 9 were confirmed after manual triage.

I am making the tool freely available, but I am not sharing for now the
C/C++ model and the optimised agent. I don't want it gets weaponised or
used improperly. If you would like to get a copy, let me know, I am ready
to handle one.

## Disclosure timeline

- 2026-04-29: All findings discovered, NFS finding reported
- 2026-04-30: Squashfs PoC confirmed, batch report sent (findings 2-5)
- 2026-07-28: Planned public disclosure (90 days from first report)

I am happy to coordinate on timing for the CVEs.

Best regards,

Vito Rallo
Peach Studio
me at vitorallo.com
https://peachstudio.be