Elektrine lite

← Feed

@errno_fail@infosec.exchange

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?

    Open ##3578795