Bug 263934 - buffer overflow in ffs_sbget() if superblock fields are broken
Summary: buffer overflow in ffs_sbget() if superblock fields are broken
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: --- Affects Some People
Assignee: Kirk McKusick
URL:
Keywords:
Depends on:
Blocks: 263979
  Show dependency treegraph
 
Reported: 2022-05-12 09:23 UTC by Robert Morris
Modified: 2022-05-18 09:23 UTC (History)
4 users (show)

See Also:


Attachments
a disk image that causes a buffer overflow during tasting, due to unexpected FFS superblock content (8.00 KB, application/octet-stream)
2022-05-12 09:23 UTC, Robert Morris
no flags Details
Proposed fix for bug 263934 (478 bytes, patch)
2022-05-12 16:20 UTC, Kirk McKusick
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Morris 2022-05-12 09:23:39 UTC
Created attachment 233866 [details]
a disk image that causes a buffer overflow during tasting, due to unexpected FFS superblock content

ffs_sbget() allocates fs->fs_cssize bytes to hold fs_csp:

        size = fs->fs_cssize;
        ...
        if ((space = UFS_MALLOC(size, filltype, M_WAITOK)) == NULL) {

but it can copy a whole fragment into that space:

        for (i = 0; i < blks; i += fs->fs_frag) {
                ...;
                        size = (blks - i) * fs->fs_fsize;
                ...;
                error = (*readfunc)(devfd,
                    dbtob(fsbtodb(fs, fs->fs_csaddr + i)), (void **)&buf, size);
                ...;
                memcpy(space, buf, size);

If fs_cssize is smaller than fs_fsize, the memcpy() can write
attacker-supplied bytes beyond the end of space.

I've attached a disk image containing garbage that looks enough like
FFS for taste to proceed, with fs_cssize = 16 and fs_fsize = 5120.

# uname -a
FreeBSD  14.0-CURRENT FreeBSD 14.0-CURRENT #224 main-n250919-29f81bc20825-dirty: Thu May 12 04:42:56 EDT 2022     rtm@zika:/usr/obj/usr/rtm/symbsd/src/riscv.riscv64/sys/RTM  riscv
# mdconfig -f taste6b.img
Memory modified after free 0xffffffd000852b40(24) val=ffffffff @ 0xffffffd000852b40   
panic: Fatal page fault at 0xffffffc00051b2b0: 0xffffffff00000070
cpuid = 0
time = 1651916658
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
page_fault_handler() at page_fault_handler+0x1aa
do_trap_supervisor() at do_trap_supervisor+0x76
cpu_exception_handler_supervisor() at cpu_exception_handler_supervisor+0x70
--- exception 13, tval = 0xffffffff00000070
mtrash_ctor() at mtrash_ctor+0x86
item_ctor() at item_ctor+0xa0
cache_alloc_item() at cache_alloc_item+0x5a
uma_zalloc_arg() at uma_zalloc_arg+0x58
uma_zalloc() at uma_zalloc+0x10
malloc() at malloc+0x80
ffs_sbget() at ffs_sbget+0x1e8
g_label_ufs_taste_common() at g_label_ufs_taste_common+0x6c
g_label_ufs_volume_taste() at g_label_ufs_volume_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 2022-05-12 16:20:49 UTC
Created attachment 233874 [details]
Proposed fix for bug 263934

Proposed fix
Comment 2 Kirk McKusick freebsd_committer 2022-05-12 16:22:23 UTC
Thanks for your report. Normally the superblock check hash would detect the corruption, but of course a hacker could update the chcek hash after corrupting the superblock.

Let me know if the attached patch solves this problem.
Comment 3 Robert Morris 2022-05-12 16:51:07 UTC
(In reply to Kirk McKusick from comment #2)
Yes -- your patch makes the problem go away for me.
Comment 4 Kirk McKusick freebsd_committer 2022-05-14 19:24:13 UTC
(In reply to Robert Morris from comment #3)
Thanks for the followup. Based on your other reported superblock corruption bugs, I believe that the correct fix is to put in a more complete set of superblock integrity checks. I will get back to you with that change in the hopes that it will cover all your submitted superblock related corruption reports.
Comment 5 Kirk McKusick freebsd_committer 2022-05-16 00:16:40 UTC
Please check to see if my proposed change in https://reviews.freebsd.org/D35219 resolves this bug. Based on your testing of my first proposed fix, it should.
Comment 6 Robert Morris 2022-05-18 09:23:55 UTC
(In reply to Kirk McKusick from comment #5)
Yes -- your validate_sblock() of Apr 12 makes this problem go away.