| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <dh6c3iksktkus55r7qkr74rclftpmxj2lbwstcvxdzc3ql3vls@c7f5ctbhg2fn>
Date: Fri, 28 Nov 2025 13:29:06 +0100
From: Jan Kara <jack@...e.cz>
To: syzbot <syzbot+94048264da5715c251f9@...kaller.appspotmail.com>
Cc: brauner@...nel.org, jack@...e.cz, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com, viro@...iv.linux.org.uk
Subject: Re: [syzbot] [fs?] general protection fault in mntput
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@...kaller.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@...glegroups.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@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists