Date: Sun, 10 Oct 2021 12:31:38 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 259041] ext2fs can read beyond the end of fs->e2fs_gd[] if a directory contains an invalid i-number Message-ID: <bug-259041-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259041 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 =3D bread(ump->um_devvp, fsbtodb(fs, ino_to_fsba(fs, ino)), (int)fs->e2fs_bsize, NOCRED, &bp)) !=3D 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 =3D 0xfffff80145589a48 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff82715cb4 stack pointer =3D 0x28:0xfffffe009bb4d540 frame pointer =3D 0x28:0xfffffe009bb4d540 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 3035 (ls) trap number =3D 12 panic: page fault cpuid =3D 0 time =3D 1633865546 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe009bb4d= 1e0 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 =3D 0xffffffff82715cb4, rsp =3D 0xfffffe009bb4d540, rbp = =3D 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 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-259041-227>