On Sat, Aug 15, 2026 at 08:44:34PM +0100, Pranav R wrote: > Hello Team, > > I am writing to follow up on the security vulnerability report I submitted > on July 23, 2026, regarding the five memory-safety findings in the FIT > cipher, squashfs, and BOOTP/DHCP components. > > Could you please provide an update on your team's verification progress for > these findings? I would also appreciate any visibility you can share > regarding the remediation timeline or planned target dates for deploying > the corresponding patches. > > Thank you for your time and continued coordination.
I don't see the original report around, I wonder where it went. Regardless, please see https://docs.u-boot.org/en/latest/develop/sending_patches.html for how to submit fixes. Thanks! > > Regards, > Pranav Rajendran > > > On Thu, Jul 23, 2026 at 11:56 PM Pranav R <[email protected]> wrote: > > > Hello Team, > > I am reporting five memory-safety vulnerabilities found during a source > > review of the current U-Boot mainline (VERSION 2026.07, development tree — > > happy to confirm against a specific commit if that's useful; my checkout > > doesn't carry git metadata). > > All are static-analysis findings, traced end-to-end from > > attacker-controlled input to the vulnerable operation; none have been > > exploited against real hardware. Detailed reports with reproduction steps > > and remediation suggestions are attached as PDFs. > > Summary of Findings > > *1. Heap buffer overflow (write) in FIT image AES-CBC decrypt* > > > > - *Location:* lib/aes/aes-decrypt.c, lib/aes.c — CONFIG_FIT_CIPHER > > - *Description:* A destination buffer is allocated to the exact > > ciphertext length, but the decrypt loop writes a block-size-rounded-up > > length with no alignment check, overflowing by up to 15 bytes on > > non-block-aligned FIT image data. > > - *Severity:* CVSS 3.1: 8.1 (High) > > - *Attachment:* U-Boot-FIT-AES-CBC-Heap-Overflow-Report.pdf > > > > *2. Heap out-of-bounds read via forged FIT data-size-unciphered* > > > > - *Location:* boot/image-fit.c, boot/image-cipher.c — CONFIG_FIT_CIPHER > > - *Description:* The post-decryption size is read from a FIT property > > outside the coverage of per-image hash/signature verification, and is > > never > > checked against the real decrypt-buffer size. > > - *Severity:* CVSS 3.1: 6.8 (Medium) > > - *Attachment:* > > U-Boot-FIT-Cipher-DataSizeUnciphered-OOB-Read-Report.pdf > > > > *3. Heap out-of-bounds reads in squashfs sqfs_frag_lookup()* > > > > - *Location:* fs/squashfs/sqfs.c — CONFIG_FS_SQUASHFS > > - *Description:* Two independent unchecked-index issues in the same > > function: a fragment-table index derived from an attacker-controlled > > superblock field with no bound against the actual allocation, and a > > metadata copy bounded by a fixed constant rather than the real buffer > > size. > > - *Severity:* CVSS 3.1: 7.1 (High) > > - *Attachment:* U-Boot-Squashfs-FragLookup-OOB-Read-Report.pdf > > > > *4. Heap out-of-bounds read via unchecked index in sqfs_dir_offset()* > > > > - *Location:* fs/squashfs/sqfs_dir.c, fs/squashfs/sqfs.c — > > CONFIG_FS_SQUASHFS > > - *Description:* The function can return a negative error code or an > > unbounded offset; all three call sites use the return value directly as > > an > > array index with no validation, including a negative-index heap underflow > > path. > > - *Severity:* CVSS 3.1: 7.1 (High) > > - *Attachment:* U-Boot-Squashfs-DirOffset-OOB-Read-Report.pdf > > > > *5. BOOTP/DHCP option parser scan window ignores received length* > > > > - *Location:* net/bootp.c — CONFIG_CMD_DHCP > > - *Description:* dhcp_packet_process_options() scans a fixed 548-byte > > window regardless of the actual received packet length, which is only > > validated down to 236 bytes. A minimal-length crafted DHCP reply causes > > stale receive-buffer content to be parsed as option data. > > - *Severity:* CVSS 3.1: 5.5 (Medium) > > - *Attachment:* U-Boot-BOOTP-DHCP-OptionScan-InfoLeak-Report.pdf > > > > Technical Context > > Each PDF includes exact file:line anchors, the full exploit chain, > > deterministic reproduction steps, a per-metric CVSS justification, CWE > > mapping, and a minimal remediation suggestion. > > I understand the project doesn't operate under NDA; I'm glad to coordinate > > on timing before any public write-up and to answer questions on any of the > > above. Let me know if a different reporting channel or additional > > recipients would be more appropriate for any of these. > > Regards, > > Pranav Rajendran > > -- Tom
signature.asc
Description: PGP signature
