[syzbot] [fs?] general protection fault in fd_install

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 4a26e7032d7d Merge tag 'core-bugs-2025-12-01' of git://git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15321512580000
kernel config: https://syzkaller.appspot.com/x/.config?x=553f3db6410d5a82
dashboard link: https://syzkaller.appspot.com/bug?extid=40f42779048f7476e2e0
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=16d76192580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16bfb8c2580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-4a26e703.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/bf3025099b65/vmlinux-4a26e703.xz
kernel image: https://storage.googleapis.com/syzbot-assets/9e022e7e7365/bzImage-4a26e703.xz

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

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000008: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047]
CPU: 0 UID: 0 PID: 5517 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:fd_install+0x57/0x3d0 fs/file.c:685
Code: 48 81 c3 48 09 00 00 48 89 d8 48 c1 e8 03 80 3c 28 00 74 08 48 89 df e8 c7 4c e6 ff 4c 8b 3b 49 8d 5e 40 48 89 d8 48 c1 e8 03 <0f> b6 04 28 84 c0 0f 85 29 03 00 00 8b 1b 89 de 81 e6 00 00 00 01
RSP: 0018:ffffc9000cb27ca0 EFLAGS: 00010202
RAX: 0000000000000008 RBX: 0000000000000041 RCX: ffff888035b14980
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000006
RBP: dffffc0000000000 R08: ffff88801c0af0e3 R09: 1ffff11003815e1c
R10: dffffc0000000000 R11: ffffed1003815e1d R12: 0000000000000006
R13: 0000000000000006 R14: 0000000000000001 R15: ffff88801f408f00
FS: 000055557b0dc500(0000) GS:ffff88808d6ba000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe4967bb43c CR3: 000000001c158000 CR4: 0000000000352ef0
Call Trace:
<TASK>
do_mq_open+0x5a0/0x770 ipc/mqueue.c:932
__do_sys_mq_open ipc/mqueue.c:945 [inline]
__se_sys_mq_open ipc/mqueue.c:938 [inline]
__x64_sys_mq_open+0x16a/0x1c0 ipc/mqueue.c:938
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f7cfa38f7c9
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:00007ffd8f2c3568 EFLAGS: 00000246 ORIG_RAX: 00000000000000f0
RAX: ffffffffffffffda RBX: 00007f7cfa5e5fa0 RCX: 00007f7cfa38f7c9
RDX: 0000000000000110 RSI: 0000000000000040 RDI: 00002000000004c0
RBP: 00007f7cfa413f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f7cfa5e5fa0 R14: 00007f7cfa5e5fa0 R15: 0000000000000004
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:fd_install+0x57/0x3d0 fs/file.c:685
Code: 48 81 c3 48 09 00 00 48 89 d8 48 c1 e8 03 80 3c 28 00 74 08 48 89 df e8 c7 4c e6 ff 4c 8b 3b 49 8d 5e 40 48 89 d8 48 c1 e8 03 <0f> b6 04 28 84 c0 0f 85 29 03 00 00 8b 1b 89 de 81 e6 00 00 00 01
RSP: 0018:ffffc9000cb27ca0 EFLAGS: 00010202
RAX: 0000000000000008 RBX: 0000000000000041 RCX: ffff888035b14980
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000006
RBP: dffffc0000000000 R08: ffff88801c0af0e3 R09: 1ffff11003815e1c
R10: dffffc0000000000 R11: ffffed1003815e1d R12: 0000000000000006
R13: 0000000000000006 R14: 0000000000000001 R15: ffff88801f408f00
FS: 000055557b0dc500(0000) GS:ffff88808d6ba000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0a4abe2fe8 CR3: 000000001c158000 CR4: 0000000000352ef0
----------------
Code disassembly (best guess):
0: 48 81 c3 48 09 00 00 add $0x948,%rbx
7: 48 89 d8 mov %rbx,%rax
a: 48 c1 e8 03 shr $0x3,%rax
e: 80 3c 28 00 cmpb $0x0,(%rax,%rbp,1)
12: 74 08 je 0x1c
14: 48 89 df mov %rbx,%rdi
17: e8 c7 4c e6 ff call 0xffe64ce3
1c: 4c 8b 3b mov (%rbx),%r15
1f: 49 8d 5e 40 lea 0x40(%r14),%rbx
23: 48 89 d8 mov %rbx,%rax
26: 48 c1 e8 03 shr $0x3,%rax
* 2a: 0f b6 04 28 movzbl (%rax,%rbp,1),%eax <-- trapping instruction
2e: 84 c0 test %al,%al
30: 0f 85 29 03 00 00 jne 0x35f
36: 8b 1b mov (%rbx),%ebx
38: 89 de mov %ebx,%esi
3a: 81 e6 00 00 00 01 and $0x1000000,%esi


---
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

[Edward Adam Davis]

#syz test

diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index 56e811f9e5fa..1fad74c5d348 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -877,7 +877,7 @@ static int prepare_open(struct dentry *dentry, int oflag, int ro,
if (!(oflag & O_CREAT))
return -ENOENT;
if (ro)
- return ro;
+ return -EROFS;
audit_inode_parent_hidden(name, dentry->d_parent);
return vfs_mkobj(dentry, mode & ~current_umask(),
mqueue_create_attr, attr);

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+40f427...@syzkaller.appspotmail.com
Tested-by: syzbot+40f427...@syzkaller.appspotmail.com

Tested on:

commit: 559e608c Merge tag 'ntfs3_for_6.19' of https://github...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=172cc01a580000
kernel config: https://syzkaller.appspot.com/x/.config?x=6301f168a3821ac6

dashboard link: https://syzkaller.appspot.com/bug?extid=40f42779048f7476e2e0
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

patch: https://syzkaller.appspot.com/x/patch.diff?x=1114c01a580000

Note: testing is done by a robot and is best-effort only.

[Edward Adam Davis]

#syz test

diff --git a/ipc/mqueue.c b/ipc/mqueue.c

index 56e811f9e5fa..90664d26ec07 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -893,7 +893,7 @@ static int prepare_open(struct dentry *dentry, int oflag, int ro,
}

static struct file *mqueue_file_open(struct filename *name,
- struct vfsmount *mnt, int oflag, bool ro,
+ struct vfsmount *mnt, int oflag, int ro,
umode_t mode, struct mq_attr *attr)
{
struct dentry *dentry;
--
2.43.0

[Edward Adam Davis]

The ro variable, being of type bool, caused the -EROFS return value from
mnt_want_write() to be implicitly converted to 1. This prevented the file
from being correctly acquired, thus triggering the issue reported by
syzbot [1].

Changing the type of ro to int allows the system to correctly identify
the reason for the file open failure.

[1]

KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047]

Call Trace:

do_mq_open+0x5a0/0x770 ipc/mqueue.c:932
__do_sys_mq_open ipc/mqueue.c:945 [inline]
__se_sys_mq_open ipc/mqueue.c:938 [inline]
__x64_sys_mq_open+0x16a/0x1c0 ipc/mqueue.c:938

Fixes: f2573685bd0c ("ipc: convert do_mq_open() to FD_ADD()")
Reported-by: syzbot+40f427...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=40f42779048f7476e2e0
Tested-by: syzbot+40f427...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <ead...@qq.com>
---
ipc/mqueue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+40f427...@syzkaller.appspotmail.com
Tested-by: syzbot+40f427...@syzkaller.appspotmail.com

Tested on:

commit: 559e608c Merge tag 'ntfs3_for_6.19' of https://github...
git tree: upstream

console output: https://syzkaller.appspot.com/x/log.txt?x=17d2c01a580000

kernel config: https://syzkaller.appspot.com/x/.config?x=6301f168a3821ac6
dashboard link: https://syzkaller.appspot.com/bug?extid=40f42779048f7476e2e0
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

patch: https://syzkaller.appspot.com/x/patch.diff?x=1082c01a580000

[Jan Kara]

On Thu 04-12-25 21:16:22, Edward Adam Davis wrote:
> The ro variable, being of type bool, caused the -EROFS return value from
> mnt_want_write() to be implicitly converted to 1. This prevented the file
> from being correctly acquired, thus triggering the issue reported by
> syzbot [1].
>
> Changing the type of ro to int allows the system to correctly identify
> the reason for the file open failure.
>
> [1]
> KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047]
> Call Trace:
> do_mq_open+0x5a0/0x770 ipc/mqueue.c:932
> __do_sys_mq_open ipc/mqueue.c:945 [inline]
> __se_sys_mq_open ipc/mqueue.c:938 [inline]
> __x64_sys_mq_open+0x16a/0x1c0 ipc/mqueue.c:938
>
> Fixes: f2573685bd0c ("ipc: convert do_mq_open() to FD_ADD()")
> Reported-by: syzbot+40f427...@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=40f42779048f7476e2e0
> Tested-by: syzbot+40f427...@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <ead...@qq.com>

Ah, indeed. mqueue_file_open() was returning ERR_PTR(1) which was confusing
FD_ADD error handling. Thanks for debugging this! Feel free to add:

Reviewed-by: Jan Kara <ja...@suse.cz>

Honza

> ---
> ipc/mqueue.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ipc/mqueue.c b/ipc/mqueue.c
> index 56e811f9e5fa..90664d26ec07 100644
> --- a/ipc/mqueue.c
> +++ b/ipc/mqueue.c
> @@ -893,7 +893,7 @@ static int prepare_open(struct dentry *dentry, int oflag, int ro,
> }
>
> static struct file *mqueue_file_open(struct filename *name,
> - struct vfsmount *mnt, int oflag, bool ro,
> + struct vfsmount *mnt, int oflag, int ro,
> umode_t mode, struct mq_attr *attr)
> {
> struct dentry *dentry;
> --
> 2.43.0
>

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

[Christian Brauner]

On Thu, 04 Dec 2025 21:16:22 +0800, Edward Adam Davis wrote:
> The ro variable, being of type bool, caused the -EROFS return value from
> mnt_want_write() to be implicitly converted to 1. This prevented the file
> from being correctly acquired, thus triggering the issue reported by
> syzbot [1].
>
> Changing the type of ro to int allows the system to correctly identify
> the reason for the file open failure.
>

> [...]

Applied to the vfs.fixes branch of the vfs/vfs.git tree.
Patches in the vfs.fixes 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.fixes

[1/1] mqueue: correct the type of ro to int
https://git.kernel.org/vfs/vfs/c/1d98eeadbc10