GHSA-c8cj-fj9j-426v: FileX fault-tolerant log replay writes past the destination sector when mounting a crafted FAT image

Mounting an attacker-controlled FAT image with fault tolerance enabled causes an out-of-bounds heap write during log replay. The write is attacker-positioned and attacker-valued, and on a common embedded memory layout it reaches the FX_MEDIA driver callback, giving control of the instruction pointer.

_fx_fault_tolerant_apply_logs replays directory log entries into a single sector staged at fx_media_memory_buffer. Both the destination offset and the copy size are read from the on-disk log. The guard before the copy bounds their sum against fx_media_memory_size, the size of the whole sector cache, rather than against fx_media_bytes_per_sector, the size of the one sector slot the copy may legitimately touch. A log entry whose offset falls inside the cache but past the sector therefore passes the check and writes outside its buffer.

The reach of that write covers fx_media_driver_entry, the callback invoked by every media operation. The replay loop issues the directory sector write-back on the line after the copy, which calls the pointer it has just overwritten, so the hijack completes inside a single iteration with no later operation required. The on-disk value is used directly, so the outcome does not depend on address-space layout.

A second, lesser problem sits at enable time: the 16-bit total_size field is trusted before the log checksum is verified, allowing an out-of-bounds read while the log file is being loaded.

An attacker who can present a crafted FAT image — removable media, or any path that lets them influence the on-disk log — gains a write primitive that yields code execution on targets without an MMU, ASLR or W^X, which describes most ThreadX deployments. Where the sector cache and the FX_MEDIA structure are not co-located, the same write corrupts adjacent heap instead.

Reachability requires FX_ENABLE_FAULT_TOLERANT at build time and an fx_fault_tolerant_enable() call at runtime. That is opt-in, but it is the configuration deployed wherever power-fail safety matters. A build without fault tolerance never replays a log and is unaffected.

Every release up to and including 6.5.1.202602 is affected.

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — 7.8, High.

Fixed in FileX 6.5.2.202603. The copy is bounded against fx_media_bytes_per_sector, the actual destination slot; the log entry budget excludes the header, the FAT chain and the content header it sits behind; and total_size is validated against the structural minimum, the format maximum and the caller’s buffer before the checksum path runs.

Build without FX_ENABLE_FAULT_TOLERANT, or do not call fx_fault_tolerant_enable(), on any product that mounts media it does not control.

Reported by @adawn0106.