[Bug 259024] ext2_search_dirblock() loops forever if e2d_reclen is zero

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 18 Oct 2021 16:03:29 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259024

--- Comment #1 from Fedor Uporov <fsu@FreeBSD.org> ---
Hi, Robert.

Thanks a lot for reports and images for reproduction.

I successfully reproduced current issue on amd64 with crash instead of infinity
loop:
#14 0xffffffff810f1927 in trap (frame=0xfffffe00af5eb7b0) at
/usr/src/sys/amd64/amd64/trap.c:443
#15 <signal handler called>
#16 ext2_search_dirblock (ip=<optimized out>, ip@entry=0xfffff80004d73900,
data=<optimized out>,
    foundp=foundp@entry=0xfffffe00af5eb990, name=0xfffff80004c87805 "a",
namelen=1, entryoffsetinblockp=<optimized out>,
    entryoffsetinblockp@entry=0xfffffe00af5eb9dc, offp=0xfffffe00af5eb9e4,
prevoffp=0xfffffe00af5eb9ac,
    endusefulp=0xfffffe00af5eb9d4, ssp=0xfffffe00af5eb978) at
/usr/src/sys/fs/ext2fs/ext2_lookup.c:743
#17 0xffffffff82746852 in ext2_lookup_ino (vdp=<optimized out>,
vpp=0xfffffe00af5ebc28, cnp=0xfffffe00af5ebc50, dd_ino=0x0)
    at /usr/src/sys/fs/ext2fs/ext2_lookup.c:455
#18 0xffffffff80cf9f16 in VOP_CACHEDLOOKUP (dvp=0xfffff800b50d3700,
vpp=0xfffffe00af5ebc28, cnp=0xfffffe00af5ebc50)
    at ./vnode_if.h:103
#19 vfs_cache_lookup (ap=<optimized out>) at /usr/src/sys/kern/vfs_cache.c:3068
#20 0xffffffff80d0b1e1 in VOP_LOOKUP (dvp=0xfffff800b50d3700,
vpp=0xfffffe00af5ebc28, cnp=0xfffffe00af5ebc50) at ./vnode_if.h:69
#21 lookup (ndp=ndp@entry=0xfffffe00af5ebbd0) at
/usr/src/sys/kern/vfs_lookup.c:1128
--Type <RET> for more, q to quit, c to continue without paging--
#22 0xffffffff80d0a0de in namei (ndp=ndp@entry=0xfffffe00af5ebbd0) at
/usr/src/sys/kern/vfs_lookup.c:658
#23 0xffffffff80d29ba2 in kern_statat (td=0xfffffe0094b47e40, flag=<optimized
out>, fd=-100,
    path=0x8018182f8 <error: Cannot access memory at address 0x8018182f8>,
pathseg=pathseg@entry=UIO_USERSPACE,
    sbp=sbp@entry=0xfffffe00af5ebd18, hook=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:2441

Issues 259105, 259107, 259112 were successfully reproduced too.

The problem with these sort of issues, I mean malicious images with
bad/corrupted metadata, that it is too difficult to make
crosscheck of metadata values read from disk. The only way to avoid it, is to
format drive with ext4 metadata_csum (RO_COMPAT_METADATA_CSUM) feature turned
on.

Need to find a way, how the metadata values, which cause a crashes, could be
verified.

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