[syzbot] [nilfs?] kernel BUG in may_open (2)

[syzbot] [nilfs?] kernel BUG in may_open (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    d7b8f8e20813 Linux 6.16-rc5
git tree:       upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=107e728c580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=72aa0474e3c3b9ac
dashboard link: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11305582580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10952bd4580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/605b3edeb031/disk-d7b8f8e2.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/a3cb6f3ea4a9/vmlinux-d7b8f8e2.xz
kernel image: https://storage.googleapis.com/syzbot-assets/cd9e0c6a9926/bzImage-d7b8f8e2.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/2a7ab270a8da/mount_0.gz

The issue was bisected to:

commit af153bb63a336a7ca0d9c8ef4ca98119c5020030
Author: Mateusz Guzik <mjguzik@gmail.com>
Date:   Sun Feb 9 18:55:21 2025 +0000

    vfs: catch invalid modes in may_open()

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17f94a8c580000
final oops:     https://syzkaller.appspot.com/x/report.txt?x=14054a8c580000
console output: https://syzkaller.appspot.com/x/log.txt?x=10054a8c580000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+895c23f6917da440ed0d@syzkaller.appspotmail.com
Fixes: af153bb63a33 ("vfs: catch invalid modes in may_open()")

VFS_BUG_ON_INODE(!IS_ANON_FILE(inode)) encountered for inode ffff8880724735b8
------------[ cut here ]------------
kernel BUG at fs/namei.c:3483!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 5842 Comm: syz-executor360 Not tainted 6.16.0-rc5-syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
RIP: 0010:may_open+0x4b1/0x4c0 fs/namei.c:3483
Code: 38 c1 0f 8c 1e fd ff ff 4c 89 e7 e8 69 25 ec ff e9 11 fd ff ff e8 9f cd 8a ff 4c 89 f7 48 c7 c6 40 40 99 8b e8 70 cb f2 fe 90 <0f> 0b 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90
RSP: 0018:ffffc90003f87940 EFLAGS: 00010246
RAX: 000000000000004d RBX: dffffc0000000000 RCX: 158c895b4c6f3300
RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
RBP: 0000000000109042 R08: ffffc90003f87667 R09: 1ffff920007f0ecc
R10: dffffc0000000000 R11: fffff520007f0ecd R12: 0000000000000000
R13: ffffffff8e29ca80 R14: ffff8880724735b8 R15: 0000000000000006
FS:  000055555ad6e380(0000) GS:ffff888125c51000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f084598dd30 CR3: 0000000073c6a000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 do_open fs/namei.c:3894 [inline]
 path_openat+0x2d91/0x3830 fs/namei.c:4055
 do_filp_open+0x1fa/0x410 fs/namei.c:4082
 do_sys_openat2+0x121/0x1c0 fs/open.c:1437
 do_sys_open fs/open.c:1452 [inline]
 __do_sys_open fs/open.c:1460 [inline]
 __se_sys_open fs/open.c:1456 [inline]
 __x64_sys_open+0x11e/0x150 fs/open.c:1456
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ffa1ddded59
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 17 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffcaa4b44f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffa1ddded59
RDX: 0000000000000000 RSI: 0000000000109042 RDI: 0000200000000000
RBP: 00007ffa1de725f0 R08: 000000000001f1b6 R09: 000055555ad6f4c0
R10: 00007ffcaa4b43c0 R11: 0000000000000246 R12: 00007ffcaa4b4520
R13: 00007ffcaa4b4748 R14: 431bde82d7b634db R15: 00007ffa1de2803b
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:may_open+0x4b1/0x4c0 fs/namei.c:3483
Code: 38 c1 0f 8c 1e fd ff ff 4c 89 e7 e8 69 25 ec ff e9 11 fd ff ff e8 9f cd 8a ff 4c 89 f7 48 c7 c6 40 40 99 8b e8 70 cb f2 fe 90 <0f> 0b 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90
RSP: 0018:ffffc90003f87940 EFLAGS: 00010246
RAX: 000000000000004d RBX: dffffc0000000000 RCX: 158c895b4c6f3300
RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
RBP: 0000000000109042 R08: ffffc90003f87667 R09: 1ffff920007f0ecc
R10: dffffc0000000000 R11: fffff520007f0ecd R12: 0000000000000000
R13: ffffffff8e29ca80 R14: ffff8880724735b8 R15: 0000000000000006
FS:  000055555ad6e380(0000) GS:ffff888125c51000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f084598dd30 CR3: 0000000073c6a000 CR4: 00000000003526f0


---
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 syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

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

Re: [syzbot] [nilfs?] kernel BUG in may_open (2)

[Jan Kara]

Hi!

On Tue 08-07-25 10:51:27, syzbot wrote:
> syzbot found the following issue on:
> 
> HEAD commit:    d7b8f8e20813 Linux 6.16-rc5
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=107e728c580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=72aa0474e3c3b9ac
> dashboard link: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d
> compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11305582580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10952bd4580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/605b3edeb031/disk-d7b8f8e2.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/a3cb6f3ea4a9/vmlinux-d7b8f8e2.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/cd9e0c6a9926/bzImage-d7b8f8e2.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/2a7ab270a8da/mount_0.gz
> 
> The issue was bisected to:
> 
> commit af153bb63a336a7ca0d9c8ef4ca98119c5020030
> Author: Mateusz Guzik <mjguzik@gmail.com>
> Date:   Sun Feb 9 18:55:21 2025 +0000
> 
>     vfs: catch invalid modes in may_open()
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17f94a8c580000
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=14054a8c580000
> console output: https://syzkaller.appspot.com/x/log.txt?x=10054a8c580000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+895c23f6917da440ed0d@syzkaller.appspotmail.com
> Fixes: af153bb63a33 ("vfs: catch invalid modes in may_open()")
> 
> VFS_BUG_ON_INODE(!IS_ANON_FILE(inode)) encountered for inode ffff8880724735b8

FWIW the reproducer just mounts a filesystem image and opens a file there
which crashes because the inode type is invalid. Which suggests there's
insufficient validation of inode metadata (in particular the inode mode)
being loaded from the disk... There are reproducers in the syzbot dashboard
for nilfs2, ntfs3, isofs, jfs. I'll take care of isofs, added other
filesystem maintainers to CC.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [syzbot] [nilfs?] kernel BUG in may_open (2)

[Ryusuke Konishi]

On Wed, Jul 9, 2025 at 5:30 PM Jan Kara wrote:
>
> Hi!
>
> On Tue 08-07-25 10:51:27, syzbot wrote:
> > syzbot found the following issue on:
> >
> > HEAD commit:    d7b8f8e20813 Linux 6.16-rc5
> > git tree:       upstream
> > console+strace: https://syzkaller.appspot.com/x/log.txt?x=107e728c580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=72aa0474e3c3b9ac
> > dashboard link: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d
> > compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11305582580000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10952bd4580000
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/605b3edeb031/disk-d7b8f8e2.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/a3cb6f3ea4a9/vmlinux-d7b8f8e2.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/cd9e0c6a9926/bzImage-d7b8f8e2.xz
> > mounted in repro: https://storage.googleapis.com/syzbot-assets/2a7ab270a8da/mount_0.gz
> >
> > The issue was bisected to:
> >
> > commit af153bb63a336a7ca0d9c8ef4ca98119c5020030
> > Author: Mateusz Guzik <mjguzik@gmail.com>
> > Date:   Sun Feb 9 18:55:21 2025 +0000
> >
> >     vfs: catch invalid modes in may_open()
> >
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17f94a8c580000
> > final oops:     https://syzkaller.appspot.com/x/report.txt?x=14054a8c580000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=10054a8c580000
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+895c23f6917da440ed0d@syzkaller.appspotmail.com
> > Fixes: af153bb63a33 ("vfs: catch invalid modes in may_open()")
> >
> > VFS_BUG_ON_INODE(!IS_ANON_FILE(inode)) encountered for inode ffff8880724735b8
>
> FWIW the reproducer just mounts a filesystem image and opens a file there
> which crashes because the inode type is invalid. Which suggests there's
> insufficient validation of inode metadata (in particular the inode mode)
> being loaded from the disk... There are reproducers in the syzbot dashboard
> for nilfs2, ntfs3, isofs, jfs. I'll take care of isofs, added other
> filesystem maintainers to CC.
>
>                                                                 Honza

Thank you for taking the initiative!
I'll deal with the nilfs2 issue.

For convenience, the correspondence between the reproducers and file
systems listed in the syzbot dashboard at the moment is as follows:

Detection time      Filesystem
2025/07/08 13:03    iso9660
2025/07/08 12:34    ntfs3
2025/07/08 12:04    nilfs2
2025/07/08 04:06    nilfs2
2025/07/08 02:39    ntfs3
2025/07/08 01:41    jfs
2025/07/08 01:56    nilfs2
2025/07/08 01:21    nilfs2
2025/07/08 01:57    iso9660
2025/07/08 02:15    jfs
2025/07/08 01:34    ntfs3

Thanks,
Ryusuke Konishi

Re: [syzbot] [nilfs?] kernel BUG in may_open (2)

[Christian Brauner]

On Wed, Jul 09, 2025 at 10:30:12AM +0200, Jan Kara wrote:
> Hi!
> 
> On Tue 08-07-25 10:51:27, syzbot wrote:
> > syzbot found the following issue on:
> > 
> > HEAD commit:    d7b8f8e20813 Linux 6.16-rc5
> > git tree:       upstream
> > console+strace: https://syzkaller.appspot.com/x/log.txt?x=107e728c580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=72aa0474e3c3b9ac
> > dashboard link: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d
> > compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11305582580000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10952bd4580000
> > 
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/605b3edeb031/disk-d7b8f8e2.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/a3cb6f3ea4a9/vmlinux-d7b8f8e2.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/cd9e0c6a9926/bzImage-d7b8f8e2.xz
> > mounted in repro: https://storage.googleapis.com/syzbot-assets/2a7ab270a8da/mount_0.gz
> > 
> > The issue was bisected to:
> > 
> > commit af153bb63a336a7ca0d9c8ef4ca98119c5020030
> > Author: Mateusz Guzik <mjguzik@gmail.com>
> > Date:   Sun Feb 9 18:55:21 2025 +0000
> > 
> >     vfs: catch invalid modes in may_open()
> > 
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17f94a8c580000
> > final oops:     https://syzkaller.appspot.com/x/report.txt?x=14054a8c580000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=10054a8c580000
> > 
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+895c23f6917da440ed0d@syzkaller.appspotmail.com
> > Fixes: af153bb63a33 ("vfs: catch invalid modes in may_open()")
> > 
> > VFS_BUG_ON_INODE(!IS_ANON_FILE(inode)) encountered for inode ffff8880724735b8
> 
> FWIW the reproducer just mounts a filesystem image and opens a file there
> which crashes because the inode type is invalid. Which suggests there's
> insufficient validation of inode metadata (in particular the inode mode)
> being loaded from the disk... There are reproducers in the syzbot dashboard
> for nilfs2, ntfs3, isofs, jfs. I'll take care of isofs, added other
> filesystem maintainers to CC.

I'm certainly happy to have added that assert.

[PATCH] nilfs2: reject invalid file types when reading inodes

[Ryusuke Konishi]

To prevent inodes with invalid file types from tripping through the
vfs and causing malfunctions or assertion failures, add a missing
sanity check when reading an inode from a block device.  If the file
type is not valid, treat it as a filesystem error.

Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Reported-by: syzbot+895c23f6917da440ed0d@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d
Cc: stable@vger.kernel.org
Fixes: 05fe58fdc10d ("nilfs2: inode operations")
---
Hi Andrew, please apply this as a bug fix.

This fixes a missing check in nilfs2 that could allow invalid file
types to be imported from corrupted filesystem images, as reported by
syzbot following a recently added VFS assertion.

Thanks,
Ryusuke Konishi

 fs/nilfs2/inode.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/nilfs2/inode.c b/fs/nilfs2/inode.c
index 6613b8fcceb0..5cf7328d5360 100644
--- a/fs/nilfs2/inode.c
+++ b/fs/nilfs2/inode.c
@@ -472,11 +472,18 @@ static int __nilfs_read_inode(struct super_block *sb,
 		inode->i_op = &nilfs_symlink_inode_operations;
 		inode_nohighmem(inode);
 		inode->i_mapping->a_ops = &nilfs_aops;
-	} else {
+	} else if (S_ISCHR(inode->i_mode) || S_ISBLK(inode->i_mode) ||
+		   S_ISFIFO(inode->i_mode) || S_ISSOCK(inode->i_mode)) {
 		inode->i_op = &nilfs_special_inode_operations;
 		init_special_inode(
 			inode, inode->i_mode,
 			huge_decode_dev(le64_to_cpu(raw_inode->i_device_code)));
+	} else {
+		nilfs_error(sb,
+			    "invalid file type bits in mode 0%o for inode %lu",
+			    inode->i_mode, ino);
+		err = -EIO;
+		goto failed_unmap;
 	}
 	nilfs_ifile_unmap_inode(raw_inode);
 	brelse(bh);
-- 
2.43.0