[syzbot] [hfs?] kernel BUG in may_open (3)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: b6151c4e60e5 Merge tag 'erofs-for-6.19-rc5-fixes' of git:/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15d45922580000
kernel config: https://syzkaller.appspot.com/x/.config?x=7b058fb1d7dbe6b1
dashboard link: https://syzkaller.appspot.com/bug?extid=f98189ed18c1f5f32e00
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=14a7d19a580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16a2f19a580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/6eb5179ada01/disk-b6151c4e.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/bc48d1a68ed0/vmlinux-b6151c4e.xz
kernel image: https://storage.googleapis.com/syzbot-assets/061d4fb696a7/bzImage-b6151c4e.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/df739de73585/mount_0.gz

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

loop0: detected capacity change from 0 to 1024
VFS_BUG_ON_INODE(!IS_ANON_FILE(inode)) encountered for inode ffff8880384b01e0
fs hfsplus mode 0 opflags 0x4 flags 0x0 state 0x70 count 2
------------[ cut here ]------------
kernel BUG at fs/namei.c:4210!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 1 UID: 0 PID: 6062 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT_{RT,(full)}
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
RIP: 0010:may_open+0x4b1/0x4c0 fs/namei.c:4210
Code: 38 c1 0f 8c 1e fd ff ff 4c 89 e7 e8 c9 ec ef ff e9 11 fd ff ff e8 df b3 8d ff 4c 89 f7 48 c7 c6 80 53 f9 8a e8 10 eb f5 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:ffffc90003ba78e0 EFLAGS: 00010282
RAX: 0000000000000088 RBX: dffffc0000000000 RCX: b41eda36b1e3ff00
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000008241 R08: 0000000000000000 R09: 0000000000000000
R10: dffffc0000000000 R11: fffff52000774ec1 R12: 0000000000000000
R13: ffffffff8d709d80 R14: ffff8880384b01e0 R15: 0000000000000002
FS: 000055557d7cd500(0000) GS:ffff888126def000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f01916a5890 CR3: 0000000040598000 CR4: 00000000003526f0
Call Trace:
<TASK>
do_open fs/namei.c:4635 [inline]
path_openat+0x32a8/0x3df0 fs/namei.c:4796
do_filp_open+0x1fa/0x410 fs/namei.c:4823
do_sys_openat2+0x121/0x200 fs/open.c:1430
do_sys_open fs/open.c:1436 [inline]
__do_sys_creat fs/open.c:1514 [inline]
__se_sys_creat fs/open.c:1508 [inline]
__x64_sys_creat+0x8f/0xc0 fs/open.c:1508
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f739c0cf749
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:00007ffd4aa21ce8 EFLAGS: 00000246 ORIG_RAX: 0000000000000055
RAX: ffffffffffffffda RBX: 00007f739c325fa0 RCX: 00007f739c0cf749
RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000200000000140
RBP: 00007f739c153f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f739c325fa0 R14: 00007f739c325fa0 R15: 0000000000000002
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:may_open+0x4b1/0x4c0 fs/namei.c:4210
Code: 38 c1 0f 8c 1e fd ff ff 4c 89 e7 e8 c9 ec ef ff e9 11 fd ff ff e8 df b3 8d ff 4c 89 f7 48 c7 c6 80 53 f9 8a e8 10 eb f5 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:ffffc90003ba78e0 EFLAGS: 00010282
RAX: 0000000000000088 RBX: dffffc0000000000 RCX: b41eda36b1e3ff00
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000008241 R08: 0000000000000000 R09: 0000000000000000
R10: dffffc0000000000 R11: fffff52000774ec1 R12: 0000000000000000
R13: ffffffff8d709d80 R14: ffff8880384b01e0 R15: 0000000000000002
FS: 000055557d7cd500(0000) GS:ffff888126def000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f01916a5890 CR3: 0000000040598000 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 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

[Christian Brauner]

On Mon, Jan 12, 2026 at 12:51:33AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: b6151c4e60e5 Merge tag 'erofs-for-6.19-rc5-fixes' of git:/..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15d45922580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=7b058fb1d7dbe6b1
> dashboard link: https://syzkaller.appspot.com/bug?extid=f98189ed18c1f5f32e00
> 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=14a7d19a580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16a2f19a580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/6eb5179ada01/disk-b6151c4e.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/bc48d1a68ed0/vmlinux-b6151c4e.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/061d4fb696a7/bzImage-b6151c4e.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/df739de73585/mount_0.gz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+f98189...@syzkaller.appspotmail.com
>
> loop0: detected capacity change from 0 to 1024
> VFS_BUG_ON_INODE(!IS_ANON_FILE(inode)) encountered for inode ffff8880384b01e0
> fs hfsplus mode 0 opflags 0x4 flags 0x0 state 0x70 count 2

This is hfsplus adding inodes with a non-valid mode.

[syzbot]

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

***

Subject: Private message regarding: [syzbot] [hfs?] kernel BUG in may_open (3)
Author: kapoor...@gmail.com

#syz test
From: Arnav Kapoor <kapoor...@gmail.com>
Date: Sun, 12 Jan 2026 14:36:00 +0000
Subject: [PATCH] hfsplus: ensure valid file mode in hfsplus_get_perms

Syzbot reported a kernel BUG in may_open() triggered by:
VFS_BUG_ON_INODE(!IS_ANON_FILE(inode), inode)

This occurs when an inode's i_mode doesn't match any standard file type
(S_IFREG, S_IFDIR, S_IFLNK, S_IFBLK, S_IFCHR, S_IFIFO, S_IFSOCK). The
crash happens when opening a file on a corrupted HFS+ filesystem where
the on-disk permissions structure has only file type bits set without
any permission bits.

In hfsplus_get_perms(), for directories, the code properly masks and
rebuilds the mode:
mode = (mode & S_IALLUGO) | S_IFDIR

However, for files with non-zero mode from disk, it directly assigns
the validated mode without ensuring permission bits are present. If
the on-disk mode is something like S_IFREG (0x8000) with no permission
bits, the inode ends up with i_mode lacking rwx bits entirely.

While such a mode passes the S_IFMT validation in the switch statement,
it creates an inode that can't be properly opened since it has no
access permissions.

Fix this by adding a check in the file path: if mode is non-zero and
valid but lacks any permission/attribute bits (S_IALLUGO mask), add
default read/write permissions like we do for the mode==0 case.

This ensures inodes always have sensible permission bits even when
reading from corrupted filesystems.

Reported-by: syzbot+f98189...@syzkaller.appspotmail.com
Tested-by: syzbot+f98189...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f98189ed18c1f5f32e00
Signed-off-by: Arnav Kapoor <kapoor...@gmail.com>
---
fs/hfsplus/inode.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/fs/hfsplus/inode.c b/fs/hfsplus/inode.c
index 000000000000..111111111111 100644
--- a/fs/hfsplus/inode.c
+++ b/fs/hfsplus/inode.c
@@ -214,10 +214,18 @@ static int hfsplus_get_perms(struct inode *inode,
inode->i_gid = sbi->gid;
if (dir) {
+ /* For directories, strip file type bits and rebuild */
mode = mode ? (mode & S_IALLUGO) : (S_IRWXUGO & ~(sbi->umask));
mode |= S_IFDIR;
- } else if (!mode)
+ } else if (!mode) {
+ /* For files with no mode, use default */
mode = S_IFREG | ((S_IRUGO|S_IWUGO) & ~(sbi->umask));
+ } else {
+ /* For files with mode, ensure we have permission bits */
+ if (!(mode & S_IALLUGO))
+ mode |= (S_IRUGO|S_IWUGO) & ~(sbi->umask);
+ }
+
inode->i_mode = mode;
HFSPLUS_I(inode)->userflags = perms->userflags;
--
2.43.0

[Tetsuo Handa]

Since commit af153bb63a33 ("vfs: catch invalid modes in may_open()")
requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/
S_IFIFO/S_IFSOCK type, use S_IFREG for special inodes.

Reported-by: syzbot <syzbot+f98189...@syzkaller.appspotmail.com>
Closes: https://syzkaller.appspot.com/bug?extid=f98189ed18c1f5f32e00
Signed-off-by: Tetsuo Handa <penguin...@I-love.SAKURA.ne.jp>
Reviewed-by: Viacheslav Dubeyko <sl...@dubeyko.com>
---
https://lkml.kernel.org/r/d0a07b1b-8b73-4002...@I-love.SAKURA.ne.jp was
a bit too late to append to previous bug report. ;-)

fs/hfsplus/super.c | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c
index aaffa9e060a0..7f327b777ece 100644
--- a/fs/hfsplus/super.c
+++ b/fs/hfsplus/super.c
@@ -53,6 +53,12 @@ static int hfsplus_system_read_inode(struct inode *inode)
return -EIO;
}

+ /*
+ * Assign a dummy file type, for may_open() requires that
+ * an inode has a valid file type.
+ */
+ inode->i_mode = S_IFREG;
+
return 0;
}

--
2.47.3

[syzbot]

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

failed to apply patch:
The next patch would create the file fs/hfsplus/inode.c,
which already exists! Applying it anyway.
checking file fs/hfsplus/inode.c
patch: **** unexpected end of file in patch



Tested on:

commit: 0f61b186 Linux 6.19-rc5
git tree: upstream

kernel config: https://syzkaller.appspot.com/x/.config?x=7b058fb1d7dbe6b1
dashboard link: https://syzkaller.appspot.com/bug?extid=f98189ed18c1f5f32e00
compiler:

patch: https://syzkaller.appspot.com/x/patch.diff?x=1072a844580000

[Dmitry Vyukov]

+hfsplus maintainers

#syz set subsystems: hfs

[Christian Brauner]

On Mon, 12 Jan 2026 18:39:23 +0900, Tetsuo Handa wrote:
> Since commit af153bb63a33 ("vfs: catch invalid modes in may_open()")
> requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/
> S_IFIFO/S_IFSOCK type, use S_IFREG for special inodes.
>
>

Applied to the vfs-7.0.misc branch of the vfs/vfs.git tree.
Patches in the vfs-7.0.misc branch should appear in linux-next soon.

Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.

It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.

Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.

tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs-7.0.misc

[1/1] hfsplus: pretend special inodes as regular files
https://git.kernel.org/vfs/vfs/c/68186fa198f1

[Viacheslav Dubeyko]

I've already taken this patch into HFS/HFS+ tree. :) Should I remove it from the
tree?

Thanks,
Slava.

[Christian Brauner]

No, I'll drop it.

[Tetsuo Handa]

I still can't see this patch in linux-next tree. What is happening?

[Viacheslav Dubeyko]

On Sun, 2026-02-01 at 13:03 +0900, Tetsuo Handa wrote:
> On 2026/01/15 1:05, Christian Brauner wrote:
> > On Tue, Jan 13, 2026 at 05:18:40PM +0000, Viacheslav Dubeyko wrote:
> > > On Tue, 2026-01-13 at 09:55 +0100, Christian Brauner wrote:
> > > > On Mon, 12 Jan 2026 18:39:23 +0900, Tetsuo Handa wrote:
> > > > > Since commit af153bb63a33 ("vfs: catch invalid modes in may_open()")
> > > > > requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/
> > > > > S_IFIFO/S_IFSOCK type, use S_IFREG for special inodes.
> > > > >
> > > > >
> > > >
> > > > Applied to the vfs-7.0.misc branch of the vfs/vfs.git tree.
> > > > Patches in the vfs-7.0.misc branch should appear in linux-next soon.
> > > >
> > > > Please report any outstanding bugs that were missed during review in a
> > > > new review to the original patch series allowing us to drop it.
> > > >
> > > > It's encouraged to provide Acked-bys and Reviewed-bys even though the
> > > > patch has now been applied. If possible patch trailers will be updated.
> > > >
> > > > Note that commit hashes shown below are subject to change due to rebase,
> > > > trailer updates or similar. If in doubt, please check the listed branch.
> > > >

> > > > tree: https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_vfs_vfs.git&d=DwICaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=q5bIm4AXMzc8NJu1_RGmnQ2fMWKq4Y4RAkElvUgSs00&m=4NRbS1i9-9rGo2YQj3jgacJN3J0YLl8S54n7yBbDwqmiGP3oIUQw19hl3LIPQpZ6&s=KhalSO4BREq2_wptIzNCJig7a9PlvlvGXkPseGPgLVw&e=

> > > > branch: vfs-7.0.misc
> > > >
> > > > [1/1] hfsplus: pretend special inodes as regular files

> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_vfs_vfs_c_68186fa198f1&d=DwICaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=q5bIm4AXMzc8NJu1_RGmnQ2fMWKq4Y4RAkElvUgSs00&m=4NRbS1i9-9rGo2YQj3jgacJN3J0YLl8S54n7yBbDwqmiGP3oIUQw19hl3LIPQpZ6&s=LBFhNyXC75hnVp8aKpJjQ9UF-_q8AIfbeoi7Caj4z-c&e=

> > >
> > > I've already taken this patch into HFS/HFS+ tree. :) Should I remove it from the
> > > tree?
> >
> > No, I'll drop it.
>
> I still can't see this patch in linux-next tree. What is happening?

The patch in HFS/HFS+ tree. I will send it in pull request for 6.20-rc1.

Thanks,
Slava.

[Tetsuo Handa]

On 2026/02/03 2:30, Viacheslav Dubeyko wrote:
>>>> I've already taken this patch into HFS/HFS+ tree. :) Should I remove it from the
>>>> tree?
>>>
>>> No, I'll drop it.
>>
>> I still can't see this patch in linux-next tree. What is happening?
>
> The patch in HFS/HFS+ tree. I will send it in pull request for 6.20-rc1.
>

Patches are expected to be tested in the linux-next tree
before sending a pull request for the linux tree.