* [syzbot] [fs?] general protection fault in mntput
@ 2025-11-27 21:42 syzbot
2025-11-28 1:35 ` Forwarded: [PATCH] fs/namespace: fix mntput of ERR_PTR in fsmount error path syzbot
2025-11-28 12:29 ` [syzbot] [fs?] general protection fault in mntput Jan Kara
0 siblings, 2 replies; 4+ messages in thread
From: syzbot @ 2025-11-27 21:42 UTC (permalink / raw)
To: brauner, jack, linux-fsdevel, linux-kernel, syzkaller-bugs, viro
Hello,
syzbot found the following issue on:
HEAD commit: 92fd6e84175b Add linux-next specific files for 20251125
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13a55612580000
kernel config: https://syzkaller.appspot.com/x/.config?x=bf77a4e0e3514deb
dashboard link: https://syzkaller.appspot.com/bug?extid=94048264da5715c251f9
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=1215f612580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17082f42580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/bee2604d495b/disk-92fd6e84.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/b12aade49e2c/vmlinux-92fd6e84.xz
kernel image: https://storage.googleapis.com/syzbot-assets/286fd34158cb/bzImage-92fd6e84.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+94048264da5715c251f9@syzkaller.appspotmail.com
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000023: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
CPU: 0 UID: 0 PID: 6414 Comm: syz.3.69 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
RIP: 0010:mntput+0x31/0xc0 fs/namespace.c:1430
Code: 41 56 41 54 53 48 89 fb e8 1c da 7e ff 48 85 db 74 47 49 bf 00 00 00 00 00 fc ff df 4c 8d b3 24 01 00 00 4d 89 f4 49 c1 ec 03 <43> 0f b6 04 3c 84 c0 75 50 48 83 c3 e0 41 8b 2e 31 ff 89 ee e8 26
RSP: 0018:ffffc9000462fd90 EFLAGS: 00010202
RAX: ffffffff8242c664 RBX: fffffffffffffff4 RCX: ffff888077aa5b80
RDX: 0000000000000000 RSI: 0000000000000000 RDI: fffffffffffffff4
RBP: ffffc9000462fed0 R08: ffff888077aa5b87 R09: 1ffff1100ef54b70
R10: dffffc0000000000 R11: ffffed100ef54b71 R12: 0000000000000023
R13: dffffc0000000000 R14: 0000000000000118 R15: dffffc0000000000
FS: 00007fdf2c77f6c0(0000) GS:ffff888125e8b000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000555575df7808 CR3: 0000000076002000 CR4: 00000000003526f0
Call Trace:
<TASK>
__do_sys_fsmount fs/namespace.c:4380 [inline]
__se_sys_fsmount+0x893/0xa90 fs/namespace.c:4279
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:0x7fdf2b98f749
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:00007fdf2c77f038 EFLAGS: 00000246 ORIG_RAX: 00000000000001b0
RAX: ffffffffffffffda RBX: 00007fdf2bbe6180 RCX: 00007fdf2b98f749
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000005
RBP: 00007fdf2ba13f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fdf2bbe6218 R14: 00007fdf2bbe6180 R15: 00007ffd8048bbc8
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:mntput+0x31/0xc0 fs/namespace.c:1430
Code: 41 56 41 54 53 48 89 fb e8 1c da 7e ff 48 85 db 74 47 49 bf 00 00 00 00 00 fc ff df 4c 8d b3 24 01 00 00 4d 89 f4 49 c1 ec 03 <43> 0f b6 04 3c 84 c0 75 50 48 83 c3 e0 41 8b 2e 31 ff 89 ee e8 26
RSP: 0018:ffffc9000462fd90 EFLAGS: 00010202
RAX: ffffffff8242c664 RBX: fffffffffffffff4 RCX: ffff888077aa5b80
RDX: 0000000000000000 RSI: 0000000000000000 RDI: fffffffffffffff4
RBP: ffffc9000462fed0 R08: ffff888077aa5b87 R09: 1ffff1100ef54b70
R10: dffffc0000000000 R11: ffffed100ef54b71 R12: 0000000000000023
R13: dffffc0000000000 R14: 0000000000000118 R15: dffffc0000000000
FS: 00007fdf2c77f6c0(0000) GS:ffff888125f8b000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd4a51d5e8 CR3: 0000000076002000 CR4: 00000000003526f0
----------------
Code disassembly (best guess):
0: 41 56 push %r14
2: 41 54 push %r12
4: 53 push %rbx
5: 48 89 fb mov %rdi,%rbx
8: e8 1c da 7e ff call 0xff7eda29
d: 48 85 db test %rbx,%rbx
10: 74 47 je 0x59
12: 49 bf 00 00 00 00 00 movabs $0xdffffc0000000000,%r15
19: fc ff df
1c: 4c 8d b3 24 01 00 00 lea 0x124(%rbx),%r14
23: 4d 89 f4 mov %r14,%r12
26: 49 c1 ec 03 shr $0x3,%r12
* 2a: 43 0f b6 04 3c movzbl (%r12,%r15,1),%eax <-- trapping instruction
2f: 84 c0 test %al,%al
31: 75 50 jne 0x83
33: 48 83 c3 e0 add $0xffffffffffffffe0,%rbx
37: 41 8b 2e mov (%r14),%ebp
3a: 31 ff xor %edi,%edi
3c: 89 ee mov %ebp,%esi
3e: e8 .byte 0xe8
3f: 26 es
---
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.
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Forwarded: [PATCH] fs/namespace: fix mntput of ERR_PTR in fsmount error path
2025-11-27 21:42 [syzbot] [fs?] general protection fault in mntput syzbot
@ 2025-11-28 1:35 ` syzbot
2025-11-28 12:29 ` [syzbot] [fs?] general protection fault in mntput Jan Kara
1 sibling, 0 replies; 4+ messages in thread
From: syzbot @ 2025-11-28 1:35 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] fs/namespace: fix mntput of ERR_PTR in fsmount error path
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
When vfs_create_mount() fails and returns an error pointer, the
__free(path_put) cleanup attribute causes path_put() to be called
on the error pointer, which then calls mntput() on an invalid
pointer value (e.g., -ENOENT = 0xfffffffffffffff4).
This results in a general protection fault in mntput() when KASAN
tries to check the shadow memory for the near-null address computed
from the error pointer offset.
Fix this by clearing newmount.mnt to NULL after extracting the error
code, preventing the path_put cleanup from operating on the error
pointer.
Reported-by: syzbot+94048264da5715c251f9@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=94048264da5715c251f9
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
fs/namespace.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index e5240df614de..236482fd503f 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -4343,8 +4343,11 @@ SYSCALL_DEFINE3(fsmount, int, fs_fd, unsigned int, flags,
warn_mandlock();
newmount.mnt = vfs_create_mount(fc);
- if (IS_ERR(newmount.mnt))
- return PTR_ERR(newmount.mnt);
+ if (IS_ERR(newmount.mnt)) {
+ ret = PTR_ERR(newmount.mnt);
+ newmount.mnt = NULL;
+ return ret;
+ }
newmount.dentry = dget(fc->root);
newmount.mnt->mnt_flags = mnt_flags;
--
2.43.0
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [syzbot] [fs?] general protection fault in mntput
2025-11-27 21:42 [syzbot] [fs?] general protection fault in mntput syzbot
2025-11-28 1:35 ` Forwarded: [PATCH] fs/namespace: fix mntput of ERR_PTR in fsmount error path syzbot
@ 2025-11-28 12:29 ` Jan Kara
2025-11-28 12:40 ` Jan Kara
1 sibling, 1 reply; 4+ messages in thread
From: Jan Kara @ 2025-11-28 12:29 UTC (permalink / raw)
To: syzbot; +Cc: brauner, jack, linux-fsdevel, linux-kernel, syzkaller-bugs, viro
Hello,
On Thu 27-11-25 13:42:27, syzbot wrote:
> syzbot found the following issue on:
>
> HEAD commit: 92fd6e84175b Add linux-next specific files for 20251125
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13a55612580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=bf77a4e0e3514deb
> dashboard link: https://syzkaller.appspot.com/bug?extid=94048264da5715c251f9
> 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=1215f612580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17082f42580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/bee2604d495b/disk-92fd6e84.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/b12aade49e2c/vmlinux-92fd6e84.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/286fd34158cb/bzImage-92fd6e84.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+94048264da5715c251f9@syzkaller.appspotmail.com
>
> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000023: 0000 [#1] SMP KASAN PTI
This is caused by 67c68da01266d ("namespace: convert fsmount() to
FD_PREPARE()") and the problem is we do:
struct path newmount __free(path_put) = {};
...
newmount.mnt = vfs_create_mount(fc);
if (IS_ERR(newmount.mnt))
return PTR_ERR(ns);
Which is not safe to do because path_put() unconditionally calls
mntput(path.mnt) which only has "if (mnt)" so it tries to put error
pointer.
There are several ways to fix this:
1) We can just add IS_ERR_OR_NULL(mnt) check to mntput(). It is convenient
but I know Al didn't like these wholesale IS_ERR_OR_NULL() checks because
they kind of hide occasional sloppy programming practices.
2) We can provide alternative for path_put() as a destructor which properly
deals with error pointers.
3) We can just store result of vfs_create_mount() in a temporary variable
and store the result in newmount after we verify it is valid.
I'm leaning towards 3) but what do other people think?
Honza
> KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
> CPU: 0 UID: 0 PID: 6414 Comm: syz.3.69 Not tainted syzkaller #0 PREEMPT(full)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
> RIP: 0010:mntput+0x31/0xc0 fs/namespace.c:1430
> Code: 41 56 41 54 53 48 89 fb e8 1c da 7e ff 48 85 db 74 47 49 bf 00 00 00 00 00 fc ff df 4c 8d b3 24 01 00 00 4d 89 f4 49 c1 ec 03 <43> 0f b6 04 3c 84 c0 75 50 48 83 c3 e0 41 8b 2e 31 ff 89 ee e8 26
> RSP: 0018:ffffc9000462fd90 EFLAGS: 00010202
> RAX: ffffffff8242c664 RBX: fffffffffffffff4 RCX: ffff888077aa5b80
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: fffffffffffffff4
> RBP: ffffc9000462fed0 R08: ffff888077aa5b87 R09: 1ffff1100ef54b70
> R10: dffffc0000000000 R11: ffffed100ef54b71 R12: 0000000000000023
> R13: dffffc0000000000 R14: 0000000000000118 R15: dffffc0000000000
> FS: 00007fdf2c77f6c0(0000) GS:ffff888125e8b000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000555575df7808 CR3: 0000000076002000 CR4: 00000000003526f0
> Call Trace:
> <TASK>
> __do_sys_fsmount fs/namespace.c:4380 [inline]
> __se_sys_fsmount+0x893/0xa90 fs/namespace.c:4279
> 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:0x7fdf2b98f749
> 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:00007fdf2c77f038 EFLAGS: 00000246 ORIG_RAX: 00000000000001b0
> RAX: ffffffffffffffda RBX: 00007fdf2bbe6180 RCX: 00007fdf2b98f749
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000005
> RBP: 00007fdf2ba13f91 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007fdf2bbe6218 R14: 00007fdf2bbe6180 R15: 00007ffd8048bbc8
> </TASK>
> Modules linked in:
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:mntput+0x31/0xc0 fs/namespace.c:1430
> Code: 41 56 41 54 53 48 89 fb e8 1c da 7e ff 48 85 db 74 47 49 bf 00 00 00 00 00 fc ff df 4c 8d b3 24 01 00 00 4d 89 f4 49 c1 ec 03 <43> 0f b6 04 3c 84 c0 75 50 48 83 c3 e0 41 8b 2e 31 ff 89 ee e8 26
> RSP: 0018:ffffc9000462fd90 EFLAGS: 00010202
> RAX: ffffffff8242c664 RBX: fffffffffffffff4 RCX: ffff888077aa5b80
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: fffffffffffffff4
> RBP: ffffc9000462fed0 R08: ffff888077aa5b87 R09: 1ffff1100ef54b70
> R10: dffffc0000000000 R11: ffffed100ef54b71 R12: 0000000000000023
> R13: dffffc0000000000 R14: 0000000000000118 R15: dffffc0000000000
> FS: 00007fdf2c77f6c0(0000) GS:ffff888125f8b000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007ffd4a51d5e8 CR3: 0000000076002000 CR4: 00000000003526f0
> ----------------
> Code disassembly (best guess):
> 0: 41 56 push %r14
> 2: 41 54 push %r12
> 4: 53 push %rbx
> 5: 48 89 fb mov %rdi,%rbx
> 8: e8 1c da 7e ff call 0xff7eda29
> d: 48 85 db test %rbx,%rbx
> 10: 74 47 je 0x59
> 12: 49 bf 00 00 00 00 00 movabs $0xdffffc0000000000,%r15
> 19: fc ff df
> 1c: 4c 8d b3 24 01 00 00 lea 0x124(%rbx),%r14
> 23: 4d 89 f4 mov %r14,%r12
> 26: 49 c1 ec 03 shr $0x3,%r12
> * 2a: 43 0f b6 04 3c movzbl (%r12,%r15,1),%eax <-- trapping instruction
> 2f: 84 c0 test %al,%al
> 31: 75 50 jne 0x83
> 33: 48 83 c3 e0 add $0xffffffffffffffe0,%rbx
> 37: 41 8b 2e mov (%r14),%ebp
> 3a: 31 ff xor %edi,%edi
> 3c: 89 ee mov %ebp,%esi
> 3e: e8 .byte 0xe8
> 3f: 26 es
>
>
> ---
> 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.
>
> 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
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [syzbot] [fs?] general protection fault in mntput
2025-11-28 12:29 ` [syzbot] [fs?] general protection fault in mntput Jan Kara
@ 2025-11-28 12:40 ` Jan Kara
0 siblings, 0 replies; 4+ messages in thread
From: Jan Kara @ 2025-11-28 12:40 UTC (permalink / raw)
To: syzbot; +Cc: brauner, jack, linux-fsdevel, linux-kernel, syzkaller-bugs, viro
On Fri 28-11-25 13:29:06, Jan Kara wrote:
> Hello,
>
> On Thu 27-11-25 13:42:27, syzbot wrote:
> > syzbot found the following issue on:
> >
> > HEAD commit: 92fd6e84175b Add linux-next specific files for 20251125
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=13a55612580000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=bf77a4e0e3514deb
> > dashboard link: https://syzkaller.appspot.com/bug?extid=94048264da5715c251f9
> > 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=1215f612580000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17082f42580000
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/bee2604d495b/disk-92fd6e84.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/b12aade49e2c/vmlinux-92fd6e84.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/286fd34158cb/bzImage-92fd6e84.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+94048264da5715c251f9@syzkaller.appspotmail.com
> >
> > Oops: general protection fault, probably for non-canonical address 0xdffffc0000000023: 0000 [#1] SMP KASAN PTI
>
> This is caused by 67c68da01266d ("namespace: convert fsmount() to
> FD_PREPARE()") and the problem is we do:
>
> struct path newmount __free(path_put) = {};
>
> ...
>
> newmount.mnt = vfs_create_mount(fc);
> if (IS_ERR(newmount.mnt))
> return PTR_ERR(ns);
>
> Which is not safe to do because path_put() unconditionally calls
> mntput(path.mnt) which only has "if (mnt)" so it tries to put error
> pointer.
>
> There are several ways to fix this:
>
> 1) We can just add IS_ERR_OR_NULL(mnt) check to mntput(). It is convenient
> but I know Al didn't like these wholesale IS_ERR_OR_NULL() checks because
> they kind of hide occasional sloppy programming practices.
>
> 2) We can provide alternative for path_put() as a destructor which properly
> deals with error pointers.
>
> 3) We can just store result of vfs_create_mount() in a temporary variable
> and store the result in newmount after we verify it is valid.
>
> I'm leaning towards 3) but what do other people think?
Ah, OK, now I see you've already picked up a fix for this so please ignore
this message.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-11-28 12:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-11-27 21:42 [syzbot] [fs?] general protection fault in mntput syzbot
2025-11-28 1:35 ` Forwarded: [PATCH] fs/namespace: fix mntput of ERR_PTR in fsmount error path syzbot
2025-11-28 12:29 ` [syzbot] [fs?] general protection fault in mntput Jan Kara
2025-11-28 12:40 ` Jan Kara
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®