Post #3578797
2026-07-04 09:18 UTC
Replies (1)
-
@errno_fail@infosec.exchange 2026-07-04 10:08
@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).