Post #3569660
2026-07-03 23:30 UTC
looking at that pile of fatfs bugs, i don't see how CVE-2026-6682 is exploitable? given the value is just used to calculate the start of actual cluster data (the end of the root directory)
as for the rest:
CVE-2026-6687 is real, a length arg should have been added with exfat support, but let's be honest, who uses f_getlabel anyway?
CVE-2026-6688 is arguably something that modern compilers should be warning on when lfn support is enabled (given that extends the 12 byte static buffer to a 256 byte static buffer) but embedded development can be a pain so yeah
CVE-2026-6685 is something that absolutely sounds like a bug that needs fixing but not a security issue, unless you're going by the linux kernel's "every bug is a CVE now" posture
any crash bug like CVE-2026-6683 or CVE-2026-6684 sounds like "eject this media and try again"
CVE-2026-6686 is literally mentioned in the documentation lol how is this a bug if you don't read the documentation of the library you're using that's just a skill issue
my conclusion: someone let an LLM loose on fatfs and asked it to find vulns didn't they
Replies (1)
-
@errno_fail@infosec.exchange 2026-07-04 08:29
@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).