Post #3578796
2026-07-04 10:08 UTC
@Rairii@labyrinth.zone,
> https://github.com/runZeroInc/vulns-2026-fatfs-chance/blob/main/02_CRITICAL.md#0-espressif-esp-idf--espressifesp-idf
Their write-up suggests that vulnerable external code trusts the file size from stat(), uses it in malloc(), then reads via read(), and read() fills more bytes than stat() reported.
The problem is: the mismatch between the reported file size and the readable data size is so common, so one must never use that stat()->malloc()->read() path.
A simple FAT corruption triggers that (the interrupted update chain is enough: the FAT records a longer cluster chain while a directory entry wasn't updated due to a power loss or a crash).
Even NTFS does that (the file size reported via readdir()-like calls can be different than the file size reported via the stat()-like calls).
Replies (1)
-
@Rairii@labyrinth.zone 2026-07-04 10:18
@errno_fail@infosec.exchange but why would a malformed fat image pointing the data inside the FAT area matter when an attacker could just change the directory entry directly?