Created attachment 233786 [details] disk image that causes taste panic in ffs_bget() due to bad fs_fsize When tasting, ffs_bget() tries to read the superblock summary information, calculating the read size from fs_bsize and fs_fsize without checking that they are plausible for FFS. This can cause an INVARIANTS kernel to panic, and a non-INVARIANTS kernel to hang. size = fs->fs_bsize; if (i + fs->fs_frag > blks) size = (blks - i) * fs->fs_fsize; buf = NULL; error = (*readfunc)(devfd, dbtob(fsbtodb(fs, fs->fs_csaddr + i)), (void **)&buf, size); This may be a duplicate of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244342 I've attached a demo disk image, containing garbage, with 49152 at the place where fs_bsize would be if it were an FFS file system, and -268744963 for fs_fsize. # uname -a FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #215 main-n250917-440e36e68279-dirty: Sat May 7 05:32:48 EDT 2022 rtm@xxx:/usr/obj/usr/rtm/symbsd/src/riscv.riscv64/sys/RTM riscv # mdconfig -f taste6a.img panic: g_read_data(): invalid length -268744963 cpuid = 0 time = 1651872649 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x38 kdb_backtrace() at kdb_backtrace+0x2c vpanic() at vpanic+0x16e panic() at panic+0x2a g_read_data() at g_read_data+0xd8 g_use_g_read_data() at g_use_g_read_data+0x26 ffs_sbget() at ffs_sbget+0x1ee g_label_ufs_taste_common() at g_label_ufs_taste_common+0x6c g_label_ufs_id_taste() at g_label_ufs_id_taste+0xe g_label_taste() at g_label_taste+0x198 g_new_provider_event() at g_new_provider_event+0xb8 one_event() at one_event+0x106 g_run_events() at g_run_events+0x8a g_event_procbody() at g_event_procbody+0x56 fork_exit() at fork_exit+0x80 fork_trampoline() at fork_trampoline+0xa KDB: enter: panic [ thread pid 13 tid 100017 ] Stopped at breakpoint+0xa: c.ldsp s0,0(sp) db>
Please check to see if my proposed change in https://reviews.freebsd.org/D35219 resolves this bug.
(In reply to Kirk McKusick from comment #1) Yes -- your validate_sblock() of Apr 12 makes this problem go away.
(In reply to Robert Morris from comment #2) Could you recheck with my updated patch of May 21 to ensure my relaxed checks did not reopen the vulnerability.
(In reply to Kirk McKusick from comment #3) Yes -- your patch of May 21 makes this problem go away for me.
Fixed by https://reviews.freebsd.org/D35219 Will close when MFC'ed to 13.
MFC'ed to 13 with commit b999366aab4e2d59cb8869b0e5ef0f70ab9b9bbe on Fri May 27 12:21:11 2022 -0700