From: syzbot <syzbot+c473aa669b5e8a6f48d2@syzkaller.appspotmail.com>
To: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, peterx@redhat.com, rppt@kernel.org,
syzkaller-bugs@googlegroups.com
Subject: [syzbot] [mm?] possible deadlock in mfill_get_vma
Date: Sun, 15 Mar 2026 11:37:28 -0700 [thread overview]
Message-ID: <69b6fc68.a00a0220.3b25d1.001e.GAE@google.com> (raw)
Hello,
syzbot found the following issue on:
HEAD commit: b84a0ebe421c Add linux-next specific files for 20260313
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=131ab8da580000
kernel config: https://syzkaller.appspot.com/x/.config?x=e7280ad1f68b2dce
dashboard link: https://syzkaller.appspot.com/bug?extid=c473aa669b5e8a6f48d2
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=126c98ba580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1644a2d6580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/09145161a8a9/disk-b84a0ebe.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/b64c254e474c/vmlinux-b84a0ebe.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a7c33f5f7f45/bzImage-b84a0ebe.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+c473aa669b5e8a6f48d2@syzkaller.appspotmail.com
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
syz.0.17/5990 is trying to acquire lock:
ffff88802caef3b8 (&mm->mmap_lock){++++}-{4:4}, at: __might_fault+0xaf/0x130 mm/memory.c:7249
but task is already holding lock:
ffff88807cdbccf0 (&ctx->map_changing_lock){.+.+}-{4:4}, at: mfill_get_vma+0x162/0x660 mm/userfaultfd.c:226
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&ctx->map_changing_lock){.+.+}-{4:4}:
down_read+0x47/0x2e0 kernel/locking/rwsem.c:1568
mfill_get_vma+0x162/0x660 mm/userfaultfd.c:226
mfill_atomic mm/userfaultfd.c:900 [inline]
mfill_atomic_continue+0x189/0x12c0 mm/userfaultfd.c:974
userfaultfd_continue fs/userfaultfd.c:1806 [inline]
userfaultfd_ioctl+0x232d/0x4c70 fs/userfaultfd.c:2071
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #1 (vm_lock){++++}-{0:0}:
__vma_start_exclude_readers+0x28a/0x940 mm/mmap_lock.c:125
__vma_start_write+0xdc/0x290 mm/mmap_lock.c:148
vma_start_write include/linux/mmap_lock.h:303 [inline]
mprotect_fixup+0x5eb/0xa80 mm/mprotect.c:768
setup_arg_pages+0x565/0xac0 fs/exec.c:670
load_elf_binary+0xc5e/0x2980 fs/binfmt_elf.c:1029
search_binary_handler fs/exec.c:1664 [inline]
exec_binprm fs/exec.c:1696 [inline]
bprm_execve+0x949/0x1470 fs/exec.c:1748
kernel_execve+0x844/0x930 fs/exec.c:1892
try_to_run_init_process+0x13/0x60 init/main.c:1514
kernel_init+0xad/0x1d0 init/main.c:1642
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #0 (&mm->mmap_lock){++++}-{4:4}:
check_prev_add kernel/locking/lockdep.c:3165 [inline]
check_prevs_add kernel/locking/lockdep.c:3284 [inline]
validate_chain kernel/locking/lockdep.c:3908 [inline]
__lock_acquire+0x15a5/0x2cf0 kernel/locking/lockdep.c:5237
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__might_fault+0xcb/0x130 mm/memory.c:7249
userfaultfd_continue fs/userfaultfd.c:1813 [inline]
userfaultfd_ioctl+0x2372/0x4c70 fs/userfaultfd.c:2071
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Chain exists of:
&mm->mmap_lock --> vm_lock --> &ctx->map_changing_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
rlock(&ctx->map_changing_lock);
lock(vm_lock);
lock(&ctx->map_changing_lock);
rlock(&mm->mmap_lock);
*** DEADLOCK ***
2 locks held by syz.0.17/5990:
#0: ffff88807c119d08 (vm_lock){++++}-{0:0}, at: lock_vma_under_rcu+0x1d1/0x500 mm/mmap_lock.c:310
#1: ffff88807cdbccf0 (&ctx->map_changing_lock){.+.+}-{4:4}, at: mfill_get_vma+0x162/0x660 mm/userfaultfd.c:226
stack backtrace:
CPU: 0 UID: 0 PID: 5990 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_circular_bug+0x2e1/0x300 kernel/locking/lockdep.c:2043
check_noncircular+0x12e/0x150 kernel/locking/lockdep.c:2175
check_prev_add kernel/locking/lockdep.c:3165 [inline]
check_prevs_add kernel/locking/lockdep.c:3284 [inline]
validate_chain kernel/locking/lockdep.c:3908 [inline]
__lock_acquire+0x15a5/0x2cf0 kernel/locking/lockdep.c:5237
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__might_fault+0xcb/0x130 mm/memory.c:7249
userfaultfd_continue fs/userfaultfd.c:1813 [inline]
userfaultfd_ioctl+0x2372/0x4c70 fs/userfaultfd.c:2071
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f478759c799
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:00007ffcc2bbac28 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f4787815fa0 RCX: 00007f478759c799
RDX: 0000200000000080 RSI: 00000000c020aa07 RDI: 0000000000000003
RBP: 00007f4787632c99 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f4787815fac R14: 00007f4787815fa0 R15: 00007f4787815fa0
</TASK>
---
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
next reply other threads:[~2026-03-15 18:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-15 18:37 syzbot [this message]
2026-03-16 0:57 ` [syzbot] [mm?] possible deadlock in mfill_get_vma Edward Adam Davis
2026-03-16 1:35 ` syzbot
2026-03-16 1:19 ` Hillf Danton
2026-03-16 1:56 ` syzbot
2026-03-16 1:49 ` Edward Adam Davis
2026-03-16 2:20 ` syzbot
2026-03-16 2:21 ` Edward Adam Davis
2026-03-16 3:07 ` syzbot
2026-03-16 3:11 ` [PATCH next] userfaultfd: unassigned vma leads to a potential unreleased locks Edward Adam Davis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=69b6fc68.a00a0220.3b25d1.001e.GAE@google.com \
--to=syzbot+c473aa669b5e8a6f48d2@syzkaller.appspotmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
--cc=rppt@kernel.org \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.