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

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

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    8e42d2514a7e Add linux-next specific files for 20260318
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10808cba580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=7f5b21566f9d8af6
dashboard link: https://syzkaller.appspot.com/bug?extid=e4470cc28308f2081ec8
compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16eb72da580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/cb90c31a24db/disk-8e42d251.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/e0c08a5de437/vmlinux-8e42d251.xz
kernel image: https://storage.googleapis.com/syzbot-assets/d6b18a5e03f8/bzImage-8e42d251.xz

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

Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI
KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127]
CPU: 1 UID: 0 PID: 15793 Comm: syz.3.4827 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
RIP: 0010:__hlist_del include/linux/list.h:992 [inline]
RIP: 0010:hlist_del_init include/linux/list.h:1020 [inline]
RIP: 0010:__umount_mnt+0x24e/0x490 fs/namespace.c:997
Code: 85 e4 74 61 4d 8d be f8 00 00 00 4c 89 f8 48 c1 e8 03 80 3c 28 00 74 08 4c 89 ff e8 fc 33 e3 ff 4d 8b 2f 4c 89 e0 48 c1 e8 03 <80> 3c 28 00 74 08 4c 89 e7 e8 d4 34 e3 ff 4d 89 2c 24 4d 85 ed 74
RSP: 0018:ffffc90003297a40 EFLAGS: 00010a06
RAX: 1bd5a00000000024 RBX: ffff8880338796c8 RCX: ffff888029f08000
RDX: 0000000000000000 RSI: ffffffff8e8d9060 RDI: ffff888033879738
RBP: dffffc0000000000 R08: ffffffff90122ff7 R09: 1ffffffff20245fe
R10: dffffc0000000000 R11: fffffbfff20245ff R12: dead000000000122
R13: dead000000000100 R14: ffff8880338796c0 R15: ffff8880338797b8
FS:  0000555561679500(0000) GS:ffff888125536000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0ebc84eddd CR3: 00000000791b8000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 umount_mnt fs/namespace.c:1008 [inline]
 umount_tree+0x925/0xd90 fs/namespace.c:1819
 put_mnt_ns+0x1d6/0x2f0 fs/namespace.c:6264
 evict+0x61e/0xb10 fs/inode.c:846
 __dentry_kill+0x1a2/0x5e0 fs/dcache.c:670
 finish_dput+0xc9/0x480 fs/dcache.c:879
 __fput+0x697/0x8c0 fs/file_table.c:508
 task_work_run+0x1d9/0x270 kernel/task_work.c:233
 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
 __exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
 exit_to_user_mode_loop+0xed/0x480 kernel/entry/common.c:98
 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:238 [inline]
 syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:269 [inline]
 syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
 do_syscall_64+0x32d/0xf80 arch/x86/entry/syscall_64.c:100
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f14bbb9c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd2857c408 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4
RAX: 0000000000000000 RBX: 00007f14bbe17da0 RCX: 00007f14bbb9c799
RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003
RBP: 00007f14bbe17da0 R08: 00007f14bbe16038 R09: 0000000000000000
R10: 000000000003fdc0 R11: 0000000000000246 R12: 0000000000033731
R13: 00007f14bbe1609c R14: 000000000003345d R15: 00007f14bbe16090
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:__hlist_del include/linux/list.h:992 [inline]
RIP: 0010:hlist_del_init include/linux/list.h:1020 [inline]
RIP: 0010:__umount_mnt+0x24e/0x490 fs/namespace.c:997
Code: 85 e4 74 61 4d 8d be f8 00 00 00 4c 89 f8 48 c1 e8 03 80 3c 28 00 74 08 4c 89 ff e8 fc 33 e3 ff 4d 8b 2f 4c 89 e0 48 c1 e8 03 <80> 3c 28 00 74 08 4c 89 e7 e8 d4 34 e3 ff 4d 89 2c 24 4d 85 ed 74
RSP: 0018:ffffc90003297a40 EFLAGS: 00010a06
RAX: 1bd5a00000000024 RBX: ffff8880338796c8 RCX: ffff888029f08000
RDX: 0000000000000000 RSI: ffffffff8e8d9060 RDI: ffff888033879738
RBP: dffffc0000000000 R08: ffffffff90122ff7 R09: 1ffffffff20245fe
R10: dffffc0000000000 R11: fffffbfff20245ff R12: dead000000000122
R13: dead000000000100 R14: ffff8880338796c0 R15: ffff8880338797b8
FS:  0000555561679500(0000) GS:ffff888125536000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0ebc84eddd CR3: 00000000791b8000 CR4: 00000000003526f0
----------------
Code disassembly (best guess):
   0:	85 e4                	test   %esp,%esp
   2:	74 61                	je     0x65
   4:	4d 8d be f8 00 00 00 	lea    0xf8(%r14),%r15
   b:	4c 89 f8             	mov    %r15,%rax
   e:	48 c1 e8 03          	shr    $0x3,%rax
  12:	80 3c 28 00          	cmpb   $0x0,(%rax,%rbp,1)
  16:	74 08                	je     0x20
  18:	4c 89 ff             	mov    %r15,%rdi
  1b:	e8 fc 33 e3 ff       	call   0xffe3341c
  20:	4d 8b 2f             	mov    (%r15),%r13
  23:	4c 89 e0             	mov    %r12,%rax
  26:	48 c1 e8 03          	shr    $0x3,%rax
* 2a:	80 3c 28 00          	cmpb   $0x0,(%rax,%rbp,1) <-- trapping instruction
  2e:	74 08                	je     0x38
  30:	4c 89 e7             	mov    %r12,%rdi
  33:	e8 d4 34 e3 ff       	call   0xffe3350c
  38:	4d 89 2c 24          	mov    %r13,(%r12)
  3c:	4d 85 ed             	test   %r13,%r13
  3f:	74                   	.byte 0x74


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

Re: [syzbot] [fs?] general protection fault in __umount_mnt

[Christian Brauner]

[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

On Fri, Mar 20, 2026 at 03:45:28PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    8e42d2514a7e Add linux-next specific files for 20260318
> git tree:       linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=10808cba580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=7f5b21566f9d8af6
> dashboard link: https://syzkaller.appspot.com/bug?extid=e4470cc28308f2081ec8
> compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16eb72da580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/cb90c31a24db/disk-8e42d251.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/e0c08a5de437/vmlinux-8e42d251.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/d6b18a5e03f8/bzImage-8e42d251.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+e4470cc28308f2081ec8@syzkaller.appspotmail.com

#syz test: https://github.com/brauner/linux/tree/vfs-7.1.mount 14594a141c760dd4c462b38d73406e1b48e44b84

[-- Attachment #2: 0001-mount-always-duplicate-mount.patch --]
[-- Type: text/x-diff, Size: 4741 bytes --]

From 14594a141c760dd4c462b38d73406e1b48e44b84 Mon Sep 17 00:00:00 2001
From: Christian Brauner <brauner@kernel.org>
Date: Mon, 23 Mar 2026 15:05:07 +0100
Subject: [PATCH] mount: always duplicate mount

In the OPEN_TREE_NAMESPACE path vfs_open_tree() resolves a path via
filename_lookup() without holding namespace_lock. Between the lookup
and create_new_namespace() acquiring namespace_lock via
LOCK_MOUNT_EXACT_COPY() another thread can unmount the mount, setting
mnt->mnt_ns to NULL.

When create_new_namespace() then checks !mnt->mnt_ns it incorrectly
takes the swap-and-mntget path that was designed for fsmount()'s
detached mounts. This reuses a mount whose mnt_mp_list is in an
inconsistent state from the concurrent unmount, causing a general
protection fault in __umount_mnt() -> hlist_del_init(&mnt->mnt_mp_list)
during namespace teardown.

Remove the !mnt->mnt_ns special case entirely. Instead, always
duplicate the mount:

 - For OPEN_TREE_NAMESPACE use __do_loopback() which will properly
   clone the mount or reject it via may_copy_tree() if it was
   unmounted in the race window.
 - For fsmount() use clone_mnt() directly (via the new MOUNT_COPY_NEW
   flag) since the mount is freshly created by vfs_create_mount() and
   not in any namespace so __do_loopback()'s IS_MNT_UNBINDABLE,
   may_copy_tree, and __has_locked_children checks don't apply.

Reported-by: syzbot+e4470cc28308f2081ec8@syzkaller.appspotmail.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
---
 fs/namespace.c | 36 +++++++++++++++---------------------
 1 file changed, 15 insertions(+), 21 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 2aebc4525cf3..090f9d951cfe 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -3086,8 +3086,13 @@ static struct file *open_detached_copy(struct path *path, unsigned int flags)
 	return file;
 }
 
+enum mount_copy_flags_t {
+	MOUNT_COPY_RECURSIVE    = (1 << 0),
+	MOUNT_COPY_NEW		= (1 << 1),
+};
+
 static struct mnt_namespace *create_new_namespace(struct path *path,
-						  bool recurse)
+						  enum mount_copy_flags_t flags)
 {
 	struct mnt_namespace *ns = current->nsproxy->mnt_ns;
 	struct user_namespace *user_ns = current_user_ns();
@@ -3096,7 +3101,7 @@ static struct mnt_namespace *create_new_namespace(struct path *path,
 	struct path to_path;
 	struct mount *mnt;
 	unsigned int copy_flags = 0;
-	bool locked = false;
+	bool locked = false, recurse = flags & MOUNT_COPY_RECURSIVE;
 
 	if (user_ns != ns->user_ns)
 		copy_flags |= CL_SLAVE;
@@ -3135,22 +3140,10 @@ static struct mnt_namespace *create_new_namespace(struct path *path,
 	 * the restrictions of creating detached bind-mounts. It has a
 	 * lot saner and simpler semantics.
 	 */
-	mnt = real_mount(path->mnt);
-	if (!mnt->mnt_ns) {
-		/*
-		 * If we're moving into a new mount namespace via
-		 * fsmount() swap the mount ids so the nullfs mount id
-		 * is the lowest in the mount namespace avoiding another
-		 * useless copy. This is fine we're not attached to any
-		 * mount namespace so the mount ids are pure decoration
-		 * at that point.
-		 */
-		swap(mnt->mnt_id_unique, new_ns_root->mnt_id_unique);
-		swap(mnt->mnt_id, new_ns_root->mnt_id);
-		mntget(&mnt->mnt);
-	} else {
+	if (flags & MOUNT_COPY_NEW)
+		mnt = clone_mnt(real_mount(path->mnt), path->dentry, copy_flags);
+	else
 		mnt = __do_loopback(path, recurse, copy_flags);
-	}
 	scoped_guard(mount_writer) {
 		if (IS_ERR(mnt)) {
 			emptied_ns = new_ns;
@@ -3179,11 +3172,12 @@ static struct mnt_namespace *create_new_namespace(struct path *path,
 	return new_ns;
 }
 
-static struct file *open_new_namespace(struct path *path, bool recurse)
+static struct file *open_new_namespace(struct path *path,
+				       enum mount_copy_flags_t flags)
 {
 	struct mnt_namespace *new_ns;
 
-	new_ns = create_new_namespace(path, recurse);
+	new_ns = create_new_namespace(path, flags);
 	if (IS_ERR(new_ns))
 		return ERR_CAST(new_ns);
 	return open_namespace_file(to_ns_common(new_ns));
@@ -3232,7 +3226,7 @@ static struct file *vfs_open_tree(int dfd, const char __user *filename, unsigned
 		return ERR_PTR(ret);
 
 	if (flags & OPEN_TREE_NAMESPACE)
-		return open_new_namespace(&path, (flags & AT_RECURSIVE));
+		return open_new_namespace(&path, (flags & AT_RECURSIVE) ? MOUNT_COPY_RECURSIVE : 0);
 
 	if (flags & OPEN_TREE_CLONE)
 		return open_detached_copy(&path, flags);
@@ -4535,7 +4529,7 @@ SYSCALL_DEFINE3(fsmount, int, fs_fd, unsigned int, flags,
 
 	if (flags & FSMOUNT_NAMESPACE)
 		return FD_ADD((flags & FSMOUNT_CLOEXEC) ? O_CLOEXEC : 0,
-			      open_new_namespace(&new_path, 0));
+			      open_new_namespace(&new_path, MOUNT_COPY_NEW));
 
 	ns = alloc_mnt_ns(current->nsproxy->mnt_ns->user_ns, true);
 	if (IS_ERR(ns))
-- 
2.47.3

Re: [syzbot] [fs?] general protection fault in __umount_mnt

[syzbot]

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

failed to checkout kernel repo https://github.com/brauner/linux/tree/vfs-7.1.mount on commit 14594a141c760dd4c462b38d73406e1b48e44b84: failed to run ["git" "fetch" "--force" "--tags" "f622b72ecc2091e74994c3e0f0d417a3c44b5855" "14594a141c760dd4c462b38d73406e1b48e44b84"]: exit status 128


Tested on:

commit:         [unknown 
git tree:       https://github.com/brauner/linux/tree/vfs-7.1.mount 14594a141c760dd4c462b38d73406e1b48e44b84
kernel config:  https://syzkaller.appspot.com/x/.config?x=c584910d0d74158d
dashboard link: https://syzkaller.appspot.com/bug?extid=e4470cc28308f2081ec8
compiler:       
patch:          https://syzkaller.appspot.com/x/patch.diff?x=11abacba580000

Re: [syzbot] [fs?] general protection fault in __umount_mnt

[Christian Brauner]

On Mon, Mar 23, 2026 at 04:17:48PM +0100, Christian Brauner wrote:
> On Fri, Mar 20, 2026 at 03:45:28PM -0700, syzbot wrote:
> > Hello,
> > 
> > syzbot found the following issue on:
> > 
> > HEAD commit:    8e42d2514a7e Add linux-next specific files for 20260318
> > git tree:       linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=10808cba580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=7f5b21566f9d8af6
> > dashboard link: https://syzkaller.appspot.com/bug?extid=e4470cc28308f2081ec8
> > compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16eb72da580000
> > 
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/cb90c31a24db/disk-8e42d251.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/e0c08a5de437/vmlinux-8e42d251.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/d6b18a5e03f8/bzImage-8e42d251.xz
> > 
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+e4470cc28308f2081ec8@syzkaller.appspotmail.com
> 
> #syz test: https://github.com/brauner/linux/tree/vfs-7.1.mount 14594a141c760dd4c462b38d73406e1b48e44b84

#syz test: https://github.com/brauner/linux.git 14594a141c760dd4c462b38d73406e1b48e44b84

Re: [syzbot] [fs?] general protection fault in __umount_mnt

[syzbot]

Hello,

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

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

Tested on:

commit:         14594a14 mount: always duplicate mount
git tree:       https://github.com/brauner/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=17e5aa06580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=d485346661badf84
dashboard link: https://syzkaller.appspot.com/bug?extid=e4470cc28308f2081ec8
compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8

Note: no patches were applied.
Note: testing is done by a robot and is best-effort only.