Created attachment 233775 [details] A disk image that causes a panic in ffs_sbget() during tasting. If ffs_sbget() sees a superblock with fs_cssize and fs_ncg equal to 0xffffffff, the kernel panics because this UFS_MALLOC() is passed a negative size: size = fs->fs_cssize; ... if (fs->fs_contigsumsize > 0) size += fs->fs_ncg * sizeof(int32_t); size += fs->fs_ncg * sizeof(u_int8_t); ... if ((space = UFS_MALLOC(size, filltype, M_WAITOK)) == NULL) { The taste system calls ffs_sbget() for any newly attached storage device. So a user can get this crash upon inserting a USB stick even if they don't try to mount it as FFS. This might be similar to or the same as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257557 but this report details the specific cause. I've attached a demo disk image: # uname -a FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #202 main-n250917-440e36e68279-dirty: Fri May 6 10:56:11 EDT 2022 rtm@xxx:/usr/obj/usr/rtm/symbsd/src/riscv.riscv64/sys/RTM riscv # mdconfig -f taste5b.img panic: Assertion size > 0 failed at /usr/rtm/symbsd/src/sys/kern/subr_vmem.c:1332 cpuid = 0 time = 1651834366 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 vmem_alloc() at vmem_alloc+0xc8 kmem_malloc_domain() at kmem_malloc_domain+0x54 kmem_malloc_domainset() at kmem_malloc_domainset+0x36 malloc_large() at malloc_large+0x2a malloc() at malloc+0xf8 ffs_sbget() at ffs_sbget+0x13c 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.