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 [email protected] https://peachstudio.be
