On Tue, Oct 27, 2026 at 02:18:37PM +0100, Oscar Deschamps wrote: > rtc_calc_weekday() indexes the 12-entry month_offset[] array with > tm->tm_mon - 1 but never checks that tm_mon is in 1..12. A caller that > derives the month from untrusted data can pass a larger value, causing an > out-of-bounds read of month_offset[]. > > fs/fat reaches this with on-disk data: fat_readdir() calls fat2rtc() on > each directory entry's cdate/date/adate fields, and fat2rtc() does > > tm->tm_mon = (date & 0x1e0) >> 5; > > The month is a 4-bit field, so it can be 0..15. A directory-entry date > word with a month of 13..15 (which a compliant filesystem never writes, > but a crafted or corrupted image can contain) makes rtc_calc_weekday() > read past month_offset[]. This happens while merely listing a FAT volume > (fatls / ls), i.e. on attacker-controlled media before it is validated. > > The impact is limited to an out-of-bounds read (a wrong weekday, or on a > sanitizer build an abort); there is no write. Reject an out-of-range > month, as is already done for the year. This also hardens the other > callers (mc146818, efi_runtime, cmd/date). > > Found with a libFuzzer harness over the FAT parser (test/fuzz/fat.c). > > Signed-off-by: Oscar Deschamps <[email protected]>
This was reported recently with: https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/ which also covers what Simon is talking about I believe. -- Tom
signature.asc
Description: PGP signature
