ext2: reject inodes with zero i_nlink and valid mode in ext2_iget()

In the Linux kernel, the following vulnerability has been resolved:

ext2: reject inodes with zero i_nlink and valid mode in ext2_iget()

ext2_iget() already rejects inodes with i_nlink == 0 when i_mode is

zero or i_dtime is set, treating them as deleted. However, the case of

i_nlink == 0 with a non-zero mode and zero dtime slips through. Since

ext2 has no orphan list, such a combination can only result from

filesystem corruption - a legitimate inode deletion always sets either

i_dtime or clears i_mode before freeing the inode.

A crafted image can exploit this gap to present such an inode to the

VFS, which then triggers WARN_ON inside drop_nlink() (fs/inode.c) via

ext2_unlink(), ext2_rename() and ext2_rmdir():

WARNING: CPU: 3 PID: 609 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336

CPU: 3 UID: 0 PID: 609 Comm: syz-executor Not tainted 6.12.77+ #1

Call Trace:

<TASK>

inode_dec_link_count include/linux/fs.h:2518 [inline]

ext2_unlink+0x26c/0x300 fs/ext2/namei.c:295

vfs_unlink+0x2fc/0x9b0 fs/namei.c:4477

do_unlinkat+0x53e/0x730 fs/namei.c:4541

__x64_sys_unlink+0xc6/0x110 fs/namei.c:4587

do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78

entry_SYSCALL_64_after_hwframe+0x77/0x7f

</TASK>

WARNING: CPU: 0 PID: 646 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336

CPU: 0 UID: 0 PID: 646 Comm: syz.0.17 Not tainted 6.12.77+ #1

Call Trace:

<TASK>

inode_dec_link_count include/linux/fs.h:2518 [inline]

ext2_rename+0x35e/0x850 fs/ext2/namei.c:374

vfs_rename+0xf2f/0x2060 fs/namei.c:5021

do_renameat2+0xbe2/0xd50 fs/namei.c:5178

__x64_sys_rename+0x7e/0xa0 fs/namei.c:5223

do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78

entry_SYSCALL_64_after_hwframe+0x77/0x7f

</TASK>

WARNING: CPU: 0 PID: 634 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336

CPU: 0 UID: 0 PID: 634 Comm: syz-executor Not tainted 6.12.77+ #1

Call Trace:

<TASK>

inode_dec_link_count include/linux/fs.h:2518 [inline]

ext2_rmdir+0xca/0x110 fs/ext2/namei.c:311

vfs_rmdir+0x204/0x690 fs/namei.c:4348

do_rmdir+0x372/0x3e0 fs/namei.c:4407

__x64_sys_unlinkat+0xf0/0x130 fs/namei.c:4577

do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78

entry_SYSCALL_64_after_hwframe+0x77/0x7f

</TASK>

Extend the existing i_nlink == 0 check to also catch this case,

reporting the corruption via ext2_error() and returning -EFSCORRUPTED.

This rejects the inode at load time and prevents it from reaching any

of the namei.c paths.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.