Bug 263822

Summary: ffs(4): malicious USB memory stick can cause panic in FFS taste code: panic: Assertion size > 0 failed at /usr/rtm/symbsd/src/sys/kern/subr_vmem.c:1332
Product: Base System Reporter: Robert Morris <rtm>
Component: kernAssignee: freebsd-fs (Nobody) <fs>
Status: Closed FIXED    
Severity: Affects Some People CC: emaste, grahamperrin, mckusick, pi
Priority: --- Keywords: crash, needs-qa
Version: UnspecifiedFlags: koobs: maintainer-feedback? (mckusick)
koobs: mfc-stable13?
koobs: mfc-stable12?
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257557
Bug Depends on:    
Bug Blocks: 263979    
Attachments:
Description Flags
A disk image that causes a panic in ffs_sbget() during tasting. none

Description Robert Morris 2022-05-06 16:54:40 UTC
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>
Comment 1 Kirk McKusick freebsd_committer freebsd_triage 2022-05-16 00:20:35 UTC
Please check to see if my proposed change in https://reviews.freebsd.org/D35219 resolves this bug.
Comment 2 Robert Morris 2022-05-18 09:25:06 UTC
(In reply to Kirk McKusick from comment #1)
Yes -- your validate_sblock() of Apr 12 makes this problem go away.
Comment 3 Kirk McKusick freebsd_committer freebsd_triage 2022-05-21 23:24:58 UTC
(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.
Comment 4 Robert Morris 2022-05-22 19:18:05 UTC
(In reply to Kirk McKusick from comment #3)
Yes -- your patch of May 21 makes this problem go away for me.
Comment 5 Kirk McKusick freebsd_committer freebsd_triage 2022-05-27 19:29:39 UTC
Fixed by https://reviews.freebsd.org/D35219

Will close when MFC'ed to 13.
Comment 6 Kirk McKusick freebsd_committer freebsd_triage 2022-11-18 22:35:50 UTC
MFC'ed to 13 with commit b999366aab4e2d59cb8869b0e5ef0f70ab9b9bbe on Fri May 27 12:21:11 2022 -0700