[syzbot] [fs?] [mm?] WARNING: bad unlock balance in hugetlb_vmdelete_list

[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=13263534580000
kernel config: https://syzkaller.appspot.com/x/.config?x=135377594f35b576
dashboard link: https://syzkaller.appspot.com/bug?extid=62edf7e27b2e8f754525
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=14a118e2580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17e204e2580000

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+62edf7...@syzkaller.appspotmail.com

=====================================
WARNING: bad unlock balance detected!
syzkaller #0 Not tainted
-------------------------------------
syz.0.8060/30977 is trying to release lock (&vma_lock->rw_sema) at:
[<ffffffff82903959>] hugetlb_vmdelete_list+0x179/0x1c0 fs/hugetlbfs/inode.c:501
but there are no more locks to release!

other info that might help us debug this:
3 locks held by syz.0.8060/30977:
#0: ffff88807d8da420 (sb_writers#12){.+.+}-{0:0}, at: mnt_want_write+0x41/0x90 fs/namespace.c:508
#1: ffff888034404648 (&sb->s_type->i_mutex_key#20){+.+.}-{4:4}, at: inode_lock_killable include/linux/fs.h:985 [inline]
#1: ffff888034404648 (&sb->s_type->i_mutex_key#20){+.+.}-{4:4}, at: do_truncate+0x171/0x220 fs/open.c:63
#2: ffff888034404918 (&hugetlbfs_i_mmap_rwsem_key){+.+.}-{4:4}, at: i_mmap_lock_write include/linux/fs.h:548 [inline]
#2: ffff888034404918 (&hugetlbfs_i_mmap_rwsem_key){+.+.}-{4:4}, at: hugetlb_vmtruncate fs/hugetlbfs/inode.c:639 [inline]
#2: ffff888034404918 (&hugetlbfs_i_mmap_rwsem_key){+.+.}-{4:4}, at: hugetlbfs_setattr+0x489/0x6d0 fs/hugetlbfs/inode.c:879

stack backtrace:
CPU: 1 UID: 0 PID: 30977 Comm: syz.0.8060 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
print_unlock_imbalance_bug+0xdc/0xf0 kernel/locking/lockdep.c:5298
__lock_release kernel/locking/lockdep.c:5537 [inline]
lock_release+0x269/0x3e0 kernel/locking/lockdep.c:5889
up_write+0x2d/0x420 kernel/locking/rwsem.c:1642
hugetlb_vmdelete_list+0x179/0x1c0 fs/hugetlbfs/inode.c:501
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:0x7fdea5b8eec9
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:00007fdea6945038 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 00007fdea5de5fa0 RCX: 00007fdea5b8eec9
RDX: 0000000000000100 RSI: 000000000014927e RDI: 0000200000000340
RBP: 00007fdea5c11f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fdea5de6038 R14: 00007fdea5de5fa0 R15: 00007ffe42e704f8
</TASK>
------------[ cut here ]------------
DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff8880295a5408, owner = 0x1, curr 0xffff8880260d9e40, list empty
WARNING: kernel/locking/rwsem.c:1381 at __up_write kernel/locking/rwsem.c:1380 [inline], CPU#1: syz.0.8060/30977
WARNING: kernel/locking/rwsem.c:1381 at up_write+0x3a2/0x420 kernel/locking/rwsem.c:1643, CPU#1: syz.0.8060/30977
Modules linked in:
CPU: 1 UID: 0 PID: 30977 Comm: syz.0.8060 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
RIP: 0010:__up_write kernel/locking/rwsem.c:1380 [inline]
RIP: 0010:up_write+0x3a2/0x420 kernel/locking/rwsem.c:1643
Code: d0 48 c7 c7 00 f0 aa 8b 48 c7 c6 20 f2 aa 8b 48 8b 14 24 4c 89 f1 4d 89 e0 4c 8b 4c 24 08 41 52 e8 b3 39 e6 ff 48 83 c4 08 90 <0f> 0b 90 90 e9 6d fd ff ff 48 c7 c1 74 0b e5 8f 80 e1 07 80 c1 03
RSP: 0018:ffffc900051076c8 EFLAGS: 00010282
RAX: b37f99c54516e500 RBX: ffff8880295a5408 RCX: ffff8880260d9e40
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000002
RBP: dffffc0000000000 R08: ffffc900051073e7 R09: 1ffff92000a20e7c
R10: dffffc0000000000 R11: fffff52000a20e7d R12: 0000000000000001
R13: ffff8880295a5460 R14: ffff8880295a5408 R15: 1ffff110052b4a82
FS: 00007fdea69456c0(0000) GS:ffff8881258a2000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fdea51fed58 CR3: 00000000779ba000 CR4: 00000000003526f0
Call Trace:
<TASK>
hugetlb_vmdelete_list+0x179/0x1c0 fs/hugetlbfs/inode.c:501
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:0x7fdea5b8eec9
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:00007fdea6945038 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 00007fdea5de5fa0 RCX: 00007fdea5b8eec9
RDX: 0000000000000100 RSI: 000000000014927e RDI: 0000200000000340
RBP: 00007fdea5c11f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fdea5de6038 R14: 00007fdea5de5fa0 R15: 00007ffe42e704f8
</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] Fix a lock imbalance bug in hugetlb_vmdelete_list() that
Author: karti...@gmail.com

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

Fix a lock imbalance bug in hugetlb_vmdelete_list() that causes:

WARNING: bad unlock balance detected!

hugetlb_vmdelete_list+0x179/0x1c0 is trying to release lock
(&vma_lock->rw_sema) but there are no more locks to release!

The issue is a race condition between multiple threads operating on the
same VMA:

1. Thread 1 calls hugetlb_vma_trylock_write() when vma->vm_private_data=NULL
2. trylock returns success (no lock needed for this VMA type)
3. Thread 2 allocates a lock structure: vma->vm_private_data=&new_lock
4. Thread 1 calls hugetlb_vma_unlock_write(), sees non-NULL vm_private_data
5. Thread 1 tries to unlock a lock it never acquired → crash

The fix is to save the VMA lock state at the time we make the locking
decision, rather than checking it again at unlock time. This prevents
the time-of-check-time-of-use (TOCTOU) race condition.

Reported-by: syzbot+62edf7...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=62edf7e27b2e8f754525
Fixes: 8d9bfb2608cf ("hugetlb: add vma based lock for pmd sharing")
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---
fs/hugetlbfs/inode.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 9e0625167517..ae3e07eacd37 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -475,15 +475,16 @@ hugetlb_vmdelete_list(struct rb_root_cached *root, pgoff_t start, pgoff_t end,
zap_flags_t zap_flags)
{
struct vm_area_struct *vma;
-
/*
* end == 0 indicates that the entire range after start should be
* unmapped. Note, end is exclusive, whereas the interval tree takes
* an inclusive "last".
*/
vma_interval_tree_foreach(vma, root, start, end ? end - 1 : ULONG_MAX) {
+ struct hugetlb_vma_lock *vma_lock;
unsigned long v_start;
unsigned long v_end;
+ vma_lock = vma->vm_private_data;

if (!hugetlb_vma_trylock_write(vma))
continue;
@@ -498,7 +499,8 @@ hugetlb_vmdelete_list(struct rb_root_cached *root, pgoff_t start, pgoff_t end,
* vmas. Therefore, lock is not held when calling
* unmap_hugepage_range for private vmas.
*/
- hugetlb_vma_unlock_write(vma);
+ if (vma_lock)
+ hugetlb_vma_unlock_write(vma);
}
}

--
2.43.0

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in hugetlb_vma_assert_locked

------------[ cut here ]------------
WARNING: mm/hugetlb.c:368 at hugetlb_vma_assert_locked+0x1dd/0x250 mm/hugetlb.c:368, CPU#1: syz.0.28/6594
Modules linked in:
CPU: 1 UID: 0 PID: 6594 Comm: syz.0.28 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 97 6e a1 ff eb 0c e8 90 6e a1 ff eb 05 e8 89 6e a1 ff 5b 41 5c 41 5d 41 5e 41 5f 5d e9 da 41 6a 09 cc e8 74 6e a1 ff 90 <0f> 0b 90 eb e5 e8 69 6e a1 ff 90 0f 0b 90 eb da 48 c7 c1 70 7c e4
RSP: 0018:ffffc90003637368 EFLAGS: 00010293
RAX: ffffffff821f22cc RBX: 0000000000000000 RCX: ffff888030330000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000001 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffff520006c6e70 R12: ffff888026856500
R13: 1ffff1100bd744fc R14: dffffc0000000000 R15: 0000000000000080
FS: 00007fb2310906c0(0000) GS:ffff8881258c5000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 00007fb23108ff98 CR3: 0000000075cce000 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+0x189/0x1f0 fs/hugetlbfs/inode.c:495
hugetlb_vmtruncate fs/hugetlbfs/inode.c:643 [inline]
hugetlbfs_setattr+0x4d1/0x6d0 fs/hugetlbfs/inode.c:881

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:1437
do_sys_open fs/open.c:1452 [inline]
__do_sys_open fs/open.c:1460 [inline]
__se_sys_open fs/open.c:1456 [inline]
__x64_sys_open+0x11e/0x150 fs/open.c:1456

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:0x7fb23018eec9

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:00007fb231090038 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 00007fb2303e5fa0 RCX: 00007fb23018eec9

RDX: 0000000000000100 RSI: 000000000014927e RDI: 0000200000000340

RBP: 00007fb230211f91 R08: 0000000000000000 R09: 0000000000000000

R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000

R13: 00007fb2303e6038 R14: 00007fb2303e5fa0 R15: 00007fff95fa5748
</TASK>


Tested on:

commit: ce7f1a98 Add linux-next specific files for 20250923
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=129a4d34580000
kernel config: https://syzkaller.appspot.com/x/.config?x=1be6fa3d47bce66e

dashboard link: https://syzkaller.appspot.com/bug?extid=62edf7e27b2e8f754525
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=17b2cce2580000

[syzbot]

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

***

Subject: [PATCH] hugetlbfs: fix lock imbalance 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() has a lock imbalance bug where lock acquisition
and release evaluate VMA conditions at different times, potentially
causing unlock to be called on the wrong lock or skipped entirely.

The current code evaluates __vma_shareable_lock() and __vma_private_lock()
twice - once during hugetlb_vma_trylock_write() and again during
hugetlb_vma_unlock_write(). If VMA state changes between these calls
(due to unmap operations or concurrent access), the lock and unlock
paths may diverge, leading to:

1. Unlocking a lock that was never acquired
2. Unlocking the wrong lock type
3. Leaving a lock held

This manifests as "bad unlock balance detected" warnings:

WARNING: bad unlock balance detected!

trying to release lock (&vma_lock->rw_sema) at:

hugetlb_vmdelete_list+0x179/0x1c0 fs/hugetlbfs/inode.c:501
but there are no more locks to release!

Fix this by saving the lock type and pointer when acquiring the lock,
then using the saved information for unlock, ensuring symmetric lock
operations regardless of any VMA state changes.

Reported-by: syzbot+62edf7...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=62edf7e27b2e8f754525

Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---

fs/hugetlbfs/inode.c | 32 +++++++++++++++++++++++++++++---
1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 9e0625167517..2721ba2ee3f3 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -42,6 +42,10 @@
#define CREATE_TRACE_POINTS
#include <trace/events/hugetlbfs.h>

+#define HPAGE_RESV_OWNER (1UL << 0)
+#define HPAGE_RESV_UNMAPPED (1UL << 1)
+#define HPAGE_RESV_MASK (HPAGE_RESV_OWNER | HPAGE_RESV_UNMAPPED)
+
static const struct address_space_operations hugetlbfs_aops;
static const struct file_operations hugetlbfs_file_operations;
static const struct inode_operations hugetlbfs_dir_inode_operations;
@@ -475,6 +479,9 @@ hugetlb_vmdelete_list(struct rb_root_cached *root, pgoff_t start, pgoff_t end,

zap_flags_t zap_flags)
{
struct vm_area_struct *vma;

+ struct hugetlb_vma_lock *vma_lock;
+ struct resv_map *resv_map;
+ bool locked;

/*
* end == 0 indicates that the entire range after start should be

@@ -484,8 +491,24 @@ hugetlb_vmdelete_list(struct rb_root_cached *root, pgoff_t start, pgoff_t end,

vma_interval_tree_foreach(vma, root, start, end ? end - 1 : ULONG_MAX) {

unsigned long v_start;
unsigned long v_end;

-
- if (!hugetlb_vma_trylock_write(vma))
+ vma_lock = NULL;
+ resv_map = NULL;
+ locked = false;
+
+ if (__vma_shareable_lock(vma)) {

+ vma_lock = vma->vm_private_data;

+ if (vma_lock && down_write_trylock(&vma_lock->rw_sema))
+ locked = true;
+ } else if (__vma_private_lock(vma)) {
+ resv_map = (struct resv_map *)((unsigned long)vma->vm_private_data & ~HPAGE_RESV_MASK);
+ if (resv_map && down_write_trylock(&resv_map->rw_sema))
+ locked = true;
+ } else {
+ /* No lock needed for this VMA */
+ locked = true;
+ }
+
+ if (!locked)
continue;

v_start = vma_offset_start(vma, start);
@@ -498,7 +521,10 @@ hugetlb_vmdelete_list(struct rb_root_cached *root, pgoff_t start, pgoff_t end,

* vmas. Therefore, lock is not held when calling
* unmap_hugepage_range for private vmas.
*/
- hugetlb_vma_unlock_write(vma);
+ if (vma_lock)

+ up_write(&vma_lock->rw_sema);
+ else if (resv_map)
+ up_write(&resv_map->rw_sema);
}
}

--
2.43.0

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in hugetlb_vma_assert_locked

------------[ cut here ]------------

WARNING: mm/hugetlb.c:368 at hugetlb_vma_assert_locked+0x1dd/0x250 mm/hugetlb.c:368, CPU#0: syz.0.2369/13821
Modules linked in:
CPU: 0 UID: 0 PID: 13821 Comm: syz.0.2369 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 e7 42 a1 ff eb 0c e8 e0 42 a1 ff eb 05 e8 d9 42 a1 ff 5b 41 5c 41 5d 41 5e 41 5f 5d e9 9a a0 6a 09 cc e8 c4 42 a1 ff 90 <0f> 0b 90 eb e5 e8 b9 42 a1 ff 90 0f 0b 90 eb da 48 c7 c1 70 b5 e4
RSP: 0018:ffffc9000c487368 EFLAGS: 00010293
RAX: ffffffff821f540c RBX: 0000000000000000 RCX: ffff88805edc1e40

RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000001 R08: 0000000000000003 R09: 0000000000000004

R10: dffffc0000000000 R11: fffff52001890e70 R12: ffff88814d805d00
R13: 1ffff1100d65a80c R14: dffffc0000000000 R15: 0000000000000080
FS: 00007f73df6f86c0(0000) GS:ffff8881257be000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 0000001b31963fff CR3: 000000002f73a000 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+0x264/0x310 fs/hugetlbfs/inode.c:517
hugetlb_vmtruncate fs/hugetlbfs/inode.c:667 [inline]
hugetlbfs_setattr+0x4d1/0x6d0 fs/hugetlbfs/inode.c:905

notify_change+0xc1a/0xf40 fs/attr.c:546
do_truncate+0x1a4/0x220 fs/open.c:68

handle_truncate fs/namei.c:3596 [inline]
do_open fs/namei.c:3979 [inline]
path_openat+0x306c/0x3830 fs/namei.c:4134
do_filp_open+0x1fa/0x410 fs/namei.c:4161

do_sys_openat2+0x121/0x1c0 fs/open.c:1437
do_sys_open fs/open.c:1452 [inline]
__do_sys_open fs/open.c:1460 [inline]
__se_sys_open fs/open.c:1456 [inline]
__x64_sys_open+0x11e/0x150 fs/open.c:1456
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:0x7f73de78eec9

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:00007f73df6f8038 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 00007f73de9e5fa0 RCX: 00007f73de78eec9

RDX: 0000000000000100 RSI: 000000000014927e RDI: 0000200000000340

RBP: 00007f73de811f91 R08: 0000000000000000 R09: 0000000000000000

R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000

R13: 00007f73de9e6038 R14: 00007f73de9e5fa0 R15: 00007ffe0f23a218
</TASK>


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=156434e2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=841973c5ab4f4157

dashboard link: https://syzkaller.appspot.com/bug?extid=62edf7e27b2e8f754525
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=114ced34580000

[Pei Xiao]

#syz test
---
drivers/tty/tty_buffer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 67271fc0b223..62d32556a24b 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -108,6 +108,7 @@ static void tty_buffer_reset(struct tty_buffer *p, size_t size)
p->lookahead = 0;
p->read = 0;
p->flags = true;
+ memset(p->data, 0, size);
}

/**
@@ -177,7 +178,7 @@ static struct tty_buffer *tty_buffer_alloc(struct tty_port *port, size_t size)
*/
if (atomic_read(&port->buf.mem_used) > port->buf.mem_limit)
return NULL;
- p = kmalloc(struct_size(p, data, 2 * size), GFP_ATOMIC | __GFP_NOWARN);
+ p = kzalloc(struct_size(p, data, 2 * size), GFP_ATOMIC | __GFP_NOWARN);
if (p == NULL)
return NULL;

--
2.25.1

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in hugetlb_vma_assert_locked

------------[ cut here ]------------

WARNING: mm/hugetlb.c:368 at hugetlb_vma_assert_locked+0x1dd/0x250 mm/hugetlb.c:368, CPU#0: syz.0.41/6582
Modules linked in:
CPU: 0 UID: 0 PID: 6582 Comm: syz.0.41 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 e7 42 a1 ff eb 0c e8 e0 42 a1 ff eb 05 e8 d9 42 a1 ff 5b 41 5c 41 5d 41 5e 41 5f 5d e9 9a a0 6a 09 cc e8 c4 42 a1 ff 90 <0f> 0b 90 eb e5 e8 b9 42 a1 ff 90 0f 0b 90 eb da 48 c7 c1 70 b5 e4

RSP: 0018:ffffc9000217f388 EFLAGS: 00010293
RAX: ffffffff821f540c RBX: 0000000000000000 RCX: ffff88807af68000

RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000001 R08: 0000000000000003 R09: 0000000000000004

R10: dffffc0000000000 R11: fffff5200042fe74 R12: ffff88805df6aa00
R13: 1ffff110064fdfc4 R14: dffffc0000000000 R15: 0000000000000080
FS: 00007fc7b46136c0(0000) GS:ffff8881257be000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 00007fc7b45f2d58 CR3: 0000000077790000 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:3596 [inline]
do_open fs/namei.c:3979 [inline]
path_openat+0x306c/0x3830 fs/namei.c:4134
do_filp_open+0x1fa/0x410 fs/namei.c:4161
do_sys_openat2+0x121/0x1c0 fs/open.c:1437
do_sys_open fs/open.c:1452 [inline]
__do_sys_open fs/open.c:1460 [inline]
__se_sys_open fs/open.c:1456 [inline]
__x64_sys_open+0x11e/0x150 fs/open.c:1456
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:0x7fc7b378eec9

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:00007fc7b4613038 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 00007fc7b39e5fa0 RCX: 00007fc7b378eec9

RDX: 0000000000000100 RSI: 000000000014927e RDI: 0000200000000340

RBP: 00007fc7b3811f91 R08: 0000000000000000 R09: 0000000000000000

R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000

R13: 00007fc7b39e6038 R14: 00007fc7b39e5fa0 R15: 00007ffc872255b8

</TASK>


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=10f02f12580000

kernel config: https://syzkaller.appspot.com/x/.config?x=841973c5ab4f4157
dashboard link: https://syzkaller.appspot.com/bug?extid=62edf7e27b2e8f754525
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=1581ed34580000

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:

KMSAN: use-after-free in n_tty_receive_buf_standard

=====================================================
BUG: KMSAN: use-after-free in n_tty_receive_char_special drivers/tty/n_tty.c:1347 [inline]
BUG: KMSAN: use-after-free in n_tty_receive_buf_standard+0x1283/0x98a0 drivers/tty/n_tty.c:1588
n_tty_receive_char_special drivers/tty/n_tty.c:1347 [inline]
n_tty_receive_buf_standard+0x1283/0x98a0 drivers/tty/n_tty.c:1588
__receive_buf drivers/tty/n_tty.c:1624 [inline]
n_tty_receive_buf_common+0x198b/0x2470 drivers/tty/n_tty.c:1723
n_tty_receive_buf2+0x4c/0x60 drivers/tty/n_tty.c:1769
tty_ldisc_receive_buf+0xc3/0x2c0 drivers/tty/tty_buffer.c:388
tty_port_default_receive_buf+0xd7/0x1a0 drivers/tty/tty_port.c:37
receive_buf drivers/tty/tty_buffer.c:446 [inline]
flush_to_ldisc+0x43e/0xe30 drivers/tty/tty_buffer.c:496
process_one_work kernel/workqueue.c:3236 [inline]
process_scheduled_works+0xa2d/0x1b80 kernel/workqueue.c:3319
worker_thread+0xedf/0x1590 kernel/workqueue.c:3400
kthread+0xd5c/0xf00 kernel/kthread.c:463
ret_from_fork+0x230/0x380 arch/x86/kernel/process.c:148
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

Uninit was created at:
slab_free_hook mm/slub.c:2348 [inline]
slab_free mm/slub.c:4695 [inline]
kfree+0x252/0xec0 mm/slub.c:4894
ieee80211_ibss_rx_queued_mgmt+0x2eea/0x3e80 net/mac80211/ibss.c:-1
ieee80211_iface_process_skb net/mac80211/iface.c:1699 [inline]
ieee80211_iface_work+0x11c7/0x1e70 net/mac80211/iface.c:1753
cfg80211_wiphy_work+0x341/0x850 net/wireless/core.c:435
process_one_work kernel/workqueue.c:3236 [inline]
process_scheduled_works+0xa2d/0x1b80 kernel/workqueue.c:3319
worker_thread+0xedf/0x1590 kernel/workqueue.c:3400
kthread+0xd5c/0xf00 kernel/kthread.c:463
ret_from_fork+0x230/0x380 arch/x86/kernel/process.c:148
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

CPU: 0 UID: 0 PID: 3884 Comm: kworker/u8:21 Not tainted syzkaller #0 PREEMPT(none)

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025

Workqueue: events_unbound flush_to_ldisc
=====================================================


Tested on:

commit: bf40f4b8 Merge tag 'probes-fixes-v6.17-rc7' of git://g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17a134e2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=f7564f7873be81d2
dashboard link: https://syzkaller.appspot.com/bug?extid=dd514b5f0cf048aec256

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=173a34e2580000