Bug 263811 - ffs(4): Disk with garbage can cause crash in taste ffs crc32 code: panic: g_read_data(): invalid length -268744963
Summary: ffs(4): Disk with garbage can cause crash in taste ffs crc32 code: panic: g_r...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-fs (Nobody)
URL:
Keywords: crash, needs-qa
Depends on:
Blocks: 263979
  Show dependency treegraph
 
Reported: 2022-05-06 10:56 UTC by Robert Morris
Modified: 2022-11-18 22:37 UTC (History)
3 users (show)

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


Attachments
a disk image that causes a page fault in the FFS taste crc32 code (8.00 KB, application/octet-stream)
2022-05-06 10:56 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 10:56:50 UTC
Created attachment 233761 [details]
a disk image that causes a page fault in the FFS taste crc32 code

If you attach a disk containing garbage that looks enough like an FFS
file system with fs_sbsize=0xffffffff, the taste code calls
calculate_crc32c() with a huge length that causes a kernel page fault.
readsuper()'s sanity-check says

  if(... && fs->fs_sbsize <= SBLOCKSIZE

fs_sbsize is signed int32, so 0xffffffff looks OK. But the crc32 code
treats the length as an unsigned, causing it to read off the end of
the block buffer.

I've included a demo:

# mdconfig -f taste5a.img
panic: vm_fault_lookup: fault on nofault entry, addr: 0xffffffc047800000
cpuid = 0
time = 1651438166
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
vm_fault_lookup() at vm_fault_lookup+0x1bc
vm_fault() at vm_fault+0x9e
vm_fault_trap() at vm_fault_trap+0x68
page_fault_handler() at page_fault_handler+0x13c
do_trap_supervisor() at do_trap_supervisor+0x76
cpu_exception_handler_supervisor() at cpu_exception_handler_supervisor+0x70
--- exception 13, tval = 0xffffffc047800000
crc32c_sb8_64_bit() at crc32c_sb8_64_bit+0xcc
multitable_crc32c() at multitable_crc32c+0x18
table_crc32c() at table_crc32c+0x22
calculate_crc32c() at calculate_crc32c+0xc
ffs_calc_sbhash() at ffs_calc_sbhash+0x28
readsuper() at readsuper+0xe2
ffs_sbget() at ffs_sbget+0xc8
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 Kubilay Kocak freebsd_committer freebsd_triage 2022-05-15 02:11:09 UTC
This appears to be a dupe of (or another case of) bug 244342
Comment 2 Kirk McKusick freebsd_committer freebsd_triage 2022-05-16 00:21:16 UTC
Please check to see if my proposed change in https://reviews.freebsd.org/D35219 resolves this bug.
Comment 3 Robert Morris 2022-05-16 17:13:47 UTC
(In reply to Kirk McKusick from comment #2)
validate_sblock() ought to check that fs_sbsize is >= 0;
without that, it's still possible to force a crash in
the crc32 code.
Comment 4 Kirk McKusick freebsd_committer freebsd_triage 2022-05-16 20:18:50 UTC
(In reply to Robert Morris from comment #3)
Right. The lower bound test should be fs->fs_sbsize < fs->fs_fsize since a zero-length superblock size would be wrong.

I am working on some other feedback about problems that the checks cause. I will do an update to the patch when I have figured them out.

Thanks for your help in identifying and fixing these vulnerabilities.
Comment 5 Kirk McKusick freebsd_committer freebsd_triage 2022-05-21 23:29:47 UTC
(In reply to Kirk McKusick from comment #4)
Can you verify that my patch of May 21 fixes this problem?
Comment 6 Robert Morris 2022-05-22 19:18:19 UTC
(In reply to Kirk McKusick from comment #5)
Yes -- your patch of May 21 makes this problem go away for me.
Comment 7 Kirk McKusick freebsd_committer freebsd_triage 2022-05-27 19:31:18 UTC
Fixed by https://reviews.freebsd.org/D35219

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