Bug 263822 - 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
Summary: ffs(4): malicious USB memory stick can cause panic in FFS taste code: panic: ...
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-fs (Nobody)
Keywords: crash, needs-qa
Depends on:
Blocks: 263979
  Show dependency treegraph
Reported: 2022-05-06 16:54 UTC by Robert Morris
Modified: 2022-05-27 19:29 UTC (History)
4 users (show)

See Also:
koobs: maintainer-feedback? (mckusick)
koobs: mfc-stable13?
koobs: mfc-stable12?

A disk image that causes a panic in ffs_sbget() during tasting. (8.00 KB, application/octet-stream)
2022-05-06 16:54 UTC, Robert Morris
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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
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)
Comment 1 Kirk McKusick freebsd_committer 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 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 2022-05-27 19:29:39 UTC
Fixed by https://reviews.freebsd.org/D35219

Will close when MFC'ed to 13.