barebox CVE-2026-34962

The attacker must be able to write a malicious ext4 filesystem image to the boot storage medium that barebox will attempt to read - this requires either physical access to the device's storage (SD card slot, JTAG, direct flash access) or a prior compromise of the running operating system with write access to the boot partition. The vulnerable code path is triggered specifically when barebox performs directory iteration on an ext4 volume, meaning the device must be configured to read files from an ext4-formatted partition at boot time. Exploitation is limited by: (1) requirement for physical media access or prior OS compromise, (2) non-default configuration - barebox must be reading from an ext4 filesystem, and (3) the SSVC automatable=no determination, meaning mass-targeted exploitation is not feasible. The impact is limited to availability; no confidentiality or integrity compromise results.

Real-world risk is constrained by the attack surface. The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:N/VA:H) indicates local access is required, meaning an attacker must control the storage media presented to the bootloader - typically requiring physical access or prior system compromise to write a malicious image to flash or removable media. EPSS at 0.01% (2nd percentile) reflects this narrow exploitation path. SSVC classifies exploitation as 'none' and automatable as 'no', consistent with the non-trivial precondition of storage media control. The technical impact is rated 'partial' by SSVC despite VA:H in CVSS, likely because denial of service in a bootloader does not exfiltrate data or modify persistent state beyond hanging the device. This is a genuine but operationally limited risk: most relevant in supply chain scenarios, physical-access threat models, or manufacturing pipelines where untrusted media might be inserted into embedded devices. Not a network-reachable, opportunistic threat.

An attacker with physical access to an embedded device crafts an ext4 filesystem image containing a directory entry where direntlen is set to zero, then writes this image to the device's boot storage (SD card, eMMC, NOR flash). When barebox attempts to resolve a path or list a directory on that partition during the next boot, ext4fs_iterate_dir() enters an infinite loop, and the device's boot process hangs indefinitely, rendering it unresponsive. No public proof-of-concept code has been identified, but the flaw is straightforward to reproduce with standard ext4 filesystem construction tools.