Maxim Suhanov

@Rairii@labyrinth.zone, yeah that makes no sense. Sounds like slop.

In 2022, Microsoft decided to propagate Mark-of-the-Web into mounted containers. Here is how they did that and why third-party code (like WinRar) still fails to correctly propagate the Zone.Identifier ADS. https://dfir.ru/2026/06/29/mark-of-the-web-the-rules-changed-the-tools-didnt/

@Rairii@labyrinth.zone,

CVE-2026-6688

Sounds like "if you don't check your buffer size, our callee is vulnerable in your caller's code"... What?

CVE-2026-6687

As a side note, Microsoft violated the spec: "According to [EXFAT 1.00], the volume label limit is 11 characters. However, at least one third-party implementation (exfatlabel) and one old official implementation (the Windows 7 exFAT driver) allow 15 characters".

CVE-2026-6682

Sounds like "you can hack your own device without using a debugger". They state that this results in a buffer overflow (reading more bytes into a fixed-size buffer).

@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).