Re: [SECURITY] Five vulnerabilities in FIT cipher, squashfs, and BOOTP/DHCP handling (mainline, VERSION 2026.07 dev)

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.

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
>