In the Linux kernel, the following vulnerability has been resolved:
ext2: reject inodes with zero inlink and valid mode in ext2iget()
ext2iget() already rejects inodes with inlink == 0 when imode is zero or idtime is set, treating them as deleted. However, the case of inlink == 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 idtime 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 WARNON inside dropnlink() (fs/inode.c) via ext2unlink(), ext2rename() and ext2_rmdir():
WARNING: CPU: 3 PID: 609 at fs/inode.c:336 dropnlink+0xad/0xd0 fs/inode.c:336 CPU: 3 UID: 0 PID: 609 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: <TASK> inodedeclinkcount include/linux/fs.h:2518 [inline] ext2unlink+0x26c/0x300 fs/ext2/namei.c:295 vfsunlink+0x2fc/0x9b0 fs/namei.c:4477 do_unlinkat+0x53e/0x730 fs/namei.c:4541 __x64sysunlink+0xc6/0x110 fs/namei.c:4587 dosyscall64+0xf5/0x220 arch/x86/entry/common.c:78 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>
WARNING: CPU: 0 PID: 646 at fs/inode.c:336 dropnlink+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> inodedeclinkcount include/linux/fs.h:2518 [inline] ext2rename+0x35e/0x850 fs/ext2/namei.c:374 vfsrename+0xf2f/0x2060 fs/namei.c:5021 do_renameat2+0xbe2/0xd50 fs/namei.c:5178 __x64sysrename+0x7e/0xa0 fs/namei.c:5223 dosyscall64+0xf5/0x220 arch/x86/entry/common.c:78 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>
WARNING: CPU: 0 PID: 634 at fs/inode.c:336 dropnlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 634 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: <TASK> inodedeclinkcount include/linux/fs.h:2518 [inline] ext2rmdir+0xca/0x110 fs/ext2/namei.c:311 vfsrmdir+0x204/0x690 fs/namei.c:4348 do_rmdir+0x372/0x3e0 fs/namei.c:4407 __x64sysunlinkat+0xf0/0x130 fs/namei.c:4577 dosyscall64+0xf5/0x220 arch/x86/entry/common.c:78 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>
Extend the existing inlink == 0 check to also catch this case, reporting the corruption via ext2error() 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.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/46xxx/CVE-2026-46002.json"
}