U-Boot CVE-2025-70292

Exploitation requires the attacker to supply a specifically crafted SquashFS filesystem image to a device running U-Boot - this demands either physical access to replace boot media (SD card, eMMC, USB flash), control of a network boot server (TFTP/PXE) from which U-Boot fetches images, or prior compromise of the host system's persistent storage. U-Boot must be compiled with SquashFS support enabled (CONFIG_FS_SQUASHFS=y in the build configuration) and must attempt to parse the malicious image at boot time. Limiting factors: no standard network-remote exploitation path exists without control of boot infrastructure; exploitation is constrained to the pre-OS phase and requires attacker influence over boot media or network boot delivery; there is no user-interaction vector once the malicious image is in place.

No CVSS vector was provided with this advisory, so all metric assessments are inferred from the technical description rather than confirmed by standardized scoring. The pre-boot attack context substantially shapes realistic risk: exploitation requires the attacker to supply a crafted SquashFS filesystem image, implying physical control of boot media, compromise of a network boot server, or prior host-level storage access - none trivially achievable at scale. No EPSS score is available, no public exploit code has been identified, and the vulnerability is absent from CISA KEV, all consistent with low current exploitation tempo. However, the complete absence of OS-level runtime mitigations in the U-Boot execution environment means successful exploitation yields full arbitrary code execution before any security controls load, representing a severe worst-case outcome. The combination of a physical-or-network-boot-server prerequisite, no confirmed active exploitation, and no standardized scoring data suggests a genuine but access-constrained vulnerability rather than a broad remote-exploitation risk. Organizations operating embedded device fleets with SquashFS-enabled U-Boot builds should treat this as an upgrade priority proportional to their physical and network-boot-server access controls.

An attacker with physical access to the target embedded device, or with control over a TFTP/PXE network boot server, delivers a crafted SquashFS image whose token list is constructed to trigger an integer overflow in sqfs_get_tokens_length(). U-Boot allocates an undersized heap buffer based on the overflowed length, and the subsequent strcpy() overwrites adjacent heap memory with attacker-controlled token data, enabling arbitrary code execution in the pre-boot environment before any OS or security controls are active.