All of lore.kernel.org
 help / color / mirror / Atom feed
From: syzbot <syzbot+f98189ed18c1f5f32e00@syzkaller.appspotmail.com>
To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Forwarded: Private message regarding: [syzbot] [hfs?] kernel BUG in may_open (3)
Date: Mon, 12 Jan 2026 01:31:21 -0800	[thread overview]
Message-ID: <6964bf69.050a0220.eaf7.0096.GAE@google.com> (raw)
In-Reply-To: <6964b615.050a0220.eaf7.0093.GAE@google.com>

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

***

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

#syz test
From: Arnav Kapoor <kapoorarnav43@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+f98189ed18c1f5f32e00@syzkaller.appspotmail.com
Tested-by: syzbot+f98189ed18c1f5f32e00@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f98189ed18c1f5f32e00
Signed-off-by: Arnav Kapoor <kapoorarnav43@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




On Monday, 12 January 2026 at 14:21:35 UTC+5:30 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 
------------[ 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 


  parent reply	other threads:[~2026-01-12  9:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-12  8:51 [syzbot] [hfs?] kernel BUG in may_open (3) syzbot
2026-01-12  9:27 ` Christian Brauner
2026-01-12  9:39   ` [PATCH v3] hfsplus: pretend special inodes as regular files Tetsuo Handa
2026-01-13  8:55     ` Christian Brauner
2026-01-13 17:18       ` Viacheslav Dubeyko
2026-01-14 16:05         ` Christian Brauner
2026-02-01  4:03           ` Tetsuo Handa
2026-02-02 17:30             ` Viacheslav Dubeyko
2026-02-02 21:50               ` Tetsuo Handa
2026-01-12 10:35   ` [syzbot] [hfs?] kernel BUG in may_open (3) Dmitry Vyukov
2026-01-12  9:31 ` syzbot [this message]
2026-02-07  9:48 ` Forwarded: " syzbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6964bf69.050a0220.eaf7.0096.GAE@google.com \
    --to=syzbot+f98189ed18c1f5f32e00@syzkaller.appspotmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.