[syzbot] [mm?] WARNING in hugetlb_vma_assert_locked

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 846bd2225ec3 Add linux-next specific files for 20250919
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=162ab8e2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=135377594f35b576
dashboard link: https://syzkaller.appspot.com/bug?extid=f26d7c75c26ec19790e7
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=173b4142580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16f504e2580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/c53d48022f8a/disk-846bd222.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/483534e784c8/vmlinux-846bd222.xz
kernel image: https://storage.googleapis.com/syzbot-assets/721b36eec9b3/bzImage-846bd222.xz

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

------------[ cut here ]------------
WARNING: mm/hugetlb.c:368 at hugetlb_vma_assert_locked+0x1dd/0x250 mm/hugetlb.c:368, CPU#0: syz.0.366/7101
Modules linked in:
CPU: 0 UID: 0 PID: 7101 Comm: syz.0.366 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
RIP: 0010:hugetlb_vma_assert_locked+0x1dd/0x250 mm/hugetlb.c:368
Code: 2e e8 17 e8 a1 ff eb 0c e8 10 e8 a1 ff eb 05 e8 09 e8 a1 ff 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 f4 e7 a1 ff 90 <0f> 0b 90 eb e5 e8 e9 e7 a1 ff 90 0f 0b 90 eb da 48 c7 c1 70 0b e5
RSP: 0018:ffffc900036b7388 EFLAGS: 00010293
RAX: ffffffff821e312c RBX: 0000000000000000 RCX: ffff88807bc95ac0
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000001 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffff520006d6e74 R12: ffff888033642a00
R13: 1ffff1100f12319c R14: dffffc0000000000 R15: 0000000000000080
FS: 00007fa9ba21d6c0(0000) GS:ffff8881257a2000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa9ba21cf98 CR3: 0000000078830000 CR4: 00000000003526f0
Call Trace:
<TASK>
huge_pmd_unshare+0x2c8/0x540 mm/hugetlb.c:7622
__unmap_hugepage_range+0x6e3/0x1aa0 mm/hugetlb.c:5901
unmap_hugepage_range+0x32e/0x410 mm/hugetlb.c:6089
hugetlb_vmdelete_list+0x171/0x1c0 fs/hugetlbfs/inode.c:494
hugetlb_vmtruncate fs/hugetlbfs/inode.c:641 [inline]
hugetlbfs_setattr+0x4d1/0x6d0 fs/hugetlbfs/inode.c:879
notify_change+0xc1a/0xf40 fs/attr.c:546
do_truncate+0x1a4/0x220 fs/open.c:68
handle_truncate fs/namei.c:3516 [inline]
do_open fs/namei.c:3899 [inline]
path_openat+0x306c/0x3830 fs/namei.c:4054
do_filp_open+0x1fa/0x410 fs/namei.c:4081
do_sys_openat2+0x121/0x1c0 fs/open.c:1435
do_sys_open fs/open.c:1450 [inline]
__do_sys_open fs/open.c:1458 [inline]
__se_sys_open fs/open.c:1454 [inline]
__x64_sys_open+0x11e/0x150 fs/open.c:1454
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fa9b938eec9
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:00007fa9ba21d038 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 00007fa9b95e5fa0 RCX: 00007fa9b938eec9
RDX: 0000000000000100 RSI: 000000000014927e RDI: 0000200000000340
RBP: 00007fa9b9411f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fa9b95e6038 R14: 00007fa9b95e5fa0 R15: 00007ffdd776dfc8
</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 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] hugetlbfs: skip VMAs without locks in hugetlb_vmdelete_list
Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

hugetlb_vmdelete_list() can call unmap_hugepage_range() on VMAs that
have no associated lock, causing assertion failures in huge_pmd_unshare().

The function hugetlb_vma_trylock_write() returns 1 (success) even when
a VMA has neither a shareable lock nor a private lock. This allows
processing to continue, but when unmap_hugepage_range() is called, it
eventually reaches huge_pmd_unshare() which calls hugetlb_vma_assert_locked()
to verify a lock is held. The assertion fails because no lock was actually
acquired.

This results in a kernel panic:

WARNING: CPU: 1 PID: 6594 Comm: syz.0.28 Not tainted
Call Trace:
hugetlb_vma_assert_locked+0x1dd/0x250
huge_pmd_unshare+0x2c8/0x540
__unmap_hugepage_range+0x6e3/0x1aa0
unmap_hugepage_range+0x32e/0x410
hugetlb_vmdelete_list+0x189/0x1f0

Fix by skipping VMAs that have no lock before calling unmap_hugepage_range(),
as the unmap operation requires lock protection.

Reported-by: syzbot+f26d7c...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f26d7c75c26ec19790e7
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---
fs/hugetlbfs/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 9e0625167517..d2ecd83848e5 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -487,7 +487,8 @@ hugetlb_vmdelete_list(struct rb_root_cached *root, pgoff_t start, pgoff_t end,

if (!hugetlb_vma_trylock_write(vma))
continue;
-
+ if (!__vma_shareable_lock(vma) && !__vma_private_lock(vma))
+ continue;
v_start = vma_offset_start(vma, start);
v_end = vma_offset_end(vma, end);

--
2.43.0

[syzbot]

Hello,

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

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

Tested on:

commit: b5a4da2c Add linux-next specific files for 20250924
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11f734e2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=841973c5ab4f4157

dashboard link: https://syzkaller.appspot.com/bug?extid=f26d7c75c26ec19790e7
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=1203ed34580000

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

[syzbot]

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

***

Subject: [PATCH] hugetlbfs: skip non-shareable VMAs in hugetlb_vmdelete_list

Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

hugetlb_vmdelete_list() processes VMAs from the i_mmap interval tree
during truncate operations. This tree should only contain shareable
(VM_MAYSHARE) mappings, as private mappings are handled through
different code paths.

However, VMAs without shareable locks can incorrectly appear in this
path, causing assertion failures in huge_pmd_unshare() when it calls
hugetlb_vma_assert_locked(). The assertion expects a lock to be held
for the VMA being processed.

When hugetlb_vma_trylock_write() succeeds but the VMA has no shareable
lock (__vma_shareable_lock returns false), the code proceeds to call
unmap_hugepage_range(). Inside this function, huge_pmd_unshare() calls
hugetlb_vma_assert_locked() which fails because no lock is actually held,
resulting in a kernel panic:

WARNING: CPU: 1 PID: 6594 Comm: syz.0.28 Not tainted
Call Trace:
hugetlb_vma_assert_locked+0x1dd/0x250
huge_pmd_unshare+0x2c8/0x540
__unmap_hugepage_range+0x6e3/0x1aa0
unmap_hugepage_range+0x32e/0x410
hugetlb_vmdelete_list+0x189/0x1f0

Fix by skipping VMAs that don't have a shareable lock. These VMAs
should not be in the shared mapping deletion path and are handled
by separate code paths for private mappings.

Reported-by: syzbot+f26d7c...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f26d7c75c26ec19790e7
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---
fs/hugetlbfs/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c

index 9e0625167517..9ba98cab3388 100644

--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -487,7 +487,8 @@ hugetlb_vmdelete_list(struct rb_root_cached *root, pgoff_t start, pgoff_t end,

if (!hugetlb_vma_trylock_write(vma))
continue;
-

+ if (!__vma_shareable_lock(vma))

[syzbot]

Hello,

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

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

Tested on:

commit: b5a4da2c Add linux-next specific files for 20250924
git tree: linux-next

console output: https://syzkaller.appspot.com/x/log.txt?x=13e0b4e2580000

kernel config: https://syzkaller.appspot.com/x/.config?x=841973c5ab4f4157
dashboard link: https://syzkaller.appspot.com/bug?extid=f26d7c75c26ec19790e7
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=14362f12580000