[Bug 259041] ext2fs can read beyond the end of fs->e2fs_gd[] if a directory contains an invalid i-number

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259041

            Bug ID: 259041
           Summary: ext2fs can read beyond the end of fs->e2fs_gd[] if a
                    directory contains an invalid i-number
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: rtm@lcs.mit.edu

ext2_lookup_ino() doesn't sanity-check i-numbers it pulls from
directory entries (i.e. ep->e2d_ino values). If an i-number is too
large, ext2 will index beyond the end of fs->e2fs_gd[]. This occurs in
this ext2_vget() code

    /* Read in the disk contents for the inode, copy into the inode. */
    if ((error = bread(ump->um_devvp, fsbtodb(fs, ino_to_fsba(fs, ino)),
        (int)fs->e2fs_bsize, NOCRED, &bp)) != 0) {

in the ino_to_fsba() macro.

Usually the index isn't too far beyond the end of e2fs_gd[], so
there's no crash; instead, ext2 uses the random-ish values obtained as
block numbers, so the result is typically a disk read error. However,
I have seen a few kernel page faults on CURRENT due to invalid
i-numbers, like this:


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xfffff80145589a48
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff82715cb4
stack pointer           = 0x28:0xfffffe009bb4d540
frame pointer           = 0x28:0xfffffe009bb4d540
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 3035 (ls)
trap number             = 12
panic: page fault
cpuid = 0
time = 1633865546
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe009bb4d1e0
vpanic() at vpanic+0x187/frame 0xfffffe009bb4d240
panic() at panic+0x43/frame 0xfffffe009bb4d2a0
trap_fatal() at trap_fatal+0x387/frame 0xfffffe009bb4d300
trap_pfault() at trap_pfault+0x99/frame 0xfffffe009bb4d360
trap() at trap+0x2a7/frame 0xfffffe009bb4d470
calltrap() at calltrap+0x8/frame 0xfffffe009bb4d470
--- trap 0xc, rip = 0xffffffff82715cb4, rsp = 0xfffffe009bb4d540, rbp =
0xfffffe009bb4d540 ---
e2fs_gd_get_i_tables() at e2fs_gd_get_i_tables+0x4/frame 0xfffffe009bb4d540
ext2_vget() at ext2_vget+0x1f9/frame 0xfffffe009bb4d5b0
ext2_lookup_ino() at ext2_lookup_ino+0x6f7/frame 0xfffffe009bb4d6c0
vfs_cache_lookup() at vfs_cache_lookup+0xa6/frame 0xfffffe009bb4d710
lookup() at lookup+0x4a1/frame 0xfffffe009bb4d7b0
namei() at namei+0x358/frame 0xfffffe009bb4d870
kern_statat() at kern_statat+0x12d/frame 0xfffffe009bb4d9c0
sys_fstatat() at sys_fstatat+0x2f/frame 0xfffffe009bb4dac0
amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe009bb4dbf0
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe009bb4dbf0

-- 
You are receiving this mail because:
You are the assignee for the bug.