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

[syzbot]

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+940482...@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 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

[syzbot]

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

***

Subject: [PATCH] fs/namespace: fix mntput of ERR_PTR in fsmount error path
Author: karti...@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+940482...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=94048264da5715c251f9
Signed-off-by: Deepanshu Kartikey <karti...@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

[syzbot]

Hello,

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

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

Tested on:

commit: ef68bf70 Add linux-next specific files for 20251127
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17c5be12580000
kernel config: https://syzkaller.appspot.com/x/.config?x=75e4ba9be1d3d04

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

patch: https://syzkaller.appspot.com/x/patch.diff?x=14cdc4b4580000

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

[Jan Kara]

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+940482...@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

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

[Jan Kara]

Ah, OK, now I see you've already picked up a fix for this so please ignore
this message.

Honza