[syzbot] [nfs?] WARNING in nsfs_fh_to_dentry

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 846bd2225ec3 Add linux-next specific files for 20250919
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=144b8d04580000
kernel config: https://syzkaller.appspot.com/x/.config?x=135377594f35b576
dashboard link: https://syzkaller.appspot.com/bug?extid=9eefe09bedd093f156c2
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1724be42580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12fc2712580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/c53d48022f8a/disk-846bd222.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/483534e784c8/vmlinux-846bd222.xz
kernel image: https://storage.googleapis.com/syzbot-assets/721b36eec9b3/bzImage-846bd222.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+9eefe0...@syzkaller.appspotmail.com

------------[ cut here ]------------
WARNING: fs/nsfs.c:493 at nsfs_fh_to_dentry+0xcc5/0xdc0 fs/nsfs.c:493, CPU#1: syz.0.17/6050
Modules linked in:
CPU: 1 UID: 0 PID: 6050 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
RIP: 0010:nsfs_fh_to_dentry+0xcc5/0xdc0 fs/nsfs.c:493
Code: 7c 24 60 e9 10 f8 ff ff e8 48 01 79 ff 90 0f 0b 90 e9 09 f6 ff ff e8 3a 01 79 ff 90 0f 0b 90 e9 81 f6 ff ff e8 2c 01 79 ff 90 <0f> 0b 90 e9 d0 f6 ff ff e8 1e 01 79 ff 45 31 ff e9 d9 f7 ff ff e8
RSP: 0018:ffffc90002f97a20 EFLAGS: 00010293
RAX: ffffffff824717f4 RBX: 00000000effffffd RCX: ffff888031990000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000effffffd
RBP: ffffc90002f97b10 R08: ffffffff8fe4db77 R09: 1ffffffff1fc9b6e
R10: dffffc0000000000 R11: fffffbfff1fc9b6f R12: 1ffff920005f2f4c
R13: ffff888028d74894 R14: dffffc0000000000 R15: 0000000000000000
FS: 0000555569cd2500(0000) GS:ffff8881258a2000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b32363fff CR3: 0000000028a1e000 CR4: 00000000003526f0
Call Trace:
<TASK>
exportfs_decode_fh_raw+0x178/0x6e0 fs/exportfs/expfs.c:456
do_handle_to_path+0xa4/0x1a0 fs/fhandle.c:276
handle_to_path fs/fhandle.c:400 [inline]
do_handle_open+0x6b4/0x8f0 fs/fhandle.c:415
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f1a5d78ec29
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffff390c9e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000130
RAX: ffffffffffffffda RBX: 00007f1a5d9d5fa0 RCX: 00007f1a5d78ec29
RDX: 0000000000400040 RSI: 0000200000000000 RDI: 0000000000000003
RBP: 00007f1a5d811e41 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f1a5d9d5fa0 R14: 00007f1a5d9d5fa0 R15: 0000000000000003
</TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] nsfs: reject file handles with invalid inode number
Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

Reject nsfs file handles that claim to have inode number 0, as no
legitimate namespace can have inode 0. This prevents a warning in
nsfs_fh_to_dentry() when open_by_handle_at() is called with malformed
file handles.

The issue occurs when userspace provides a file handle with valid
namespace type and ID but claims the namespace has inode number 0.
The namespace lookup succeeds but triggers VFS_WARN_ON_ONCE() when
comparing the real inode number against the impossible claim of 0.

Since inode 0 is reserved in all filesystems and no namespace can
legitimately have inode 0, we can safely reject such handles early
to prevent reaching the consistency check that triggers the warning.

Testing confirmed that other invalid inode numbers (1, 255) do not
trigger the same issue, indicating this is specific to inode 0 rather
than a general problem with incorrect inode numbers.


Reported-by: syzbot+9eefe0...@syzkaller.appspotmail.com
Tested-by: syzbot+9eefe0...@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>

---
fs/nsfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nsfs.c b/fs/nsfs.c
index 32cb8c835a2b..42672cec293c 100644
--- a/fs/nsfs.c
+++ b/fs/nsfs.c
@@ -469,7 +469,8 @@ static struct dentry *nsfs_fh_to_dentry(struct super_block *sb, struct fid *fh,

if (fh_len < NSFS_FID_SIZE_U32_VER0)
return NULL;
-
+ if (fid->ns_inum == 0)
+ return NULL;
/* Check that any trailing bytes are zero. */
if ((fh_len > NSFS_FID_SIZE_U32_LATEST) &&
memchr_inv((void *)fid + NSFS_FID_SIZE_U32_LATEST, 0,
--
2.43.0