* [syzbot] [mm?] KASAN: slab-use-after-free Read in madvise_walk_vmas
@ 2026-03-31 9:07 syzbot
2026-03-31 10:52 ` Lorenzo Stoakes (Oracle)
2026-03-31 11:43 ` Lorenzo Stoakes (Oracle)
0 siblings, 2 replies; 4+ messages in thread
From: syzbot @ 2026-03-31 9:07 UTC (permalink / raw)
To: Liam.Howlett, akpm, david, jannh, linux-kernel, linux-mm, ljs,
syzkaller-bugs, vbabka
Hello,
syzbot found the following issue on:
HEAD commit: e77a5a5cfe43 Add linux-next specific files for 20260326
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13640f52580000
kernel config: https://syzkaller.appspot.com/x/.config?x=51ca7cbda5f81780
dashboard link: https://syzkaller.appspot.com/bug?extid=001b9efd14d3e8fac896
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/63883a48e879/disk-e77a5a5c.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/cfdff9b548ab/vmlinux-e77a5a5c.xz
kernel image: https://storage.googleapis.com/syzbot-assets/f2e4eca37d44/bzImage-e77a5a5c.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+001b9efd14d3e8fac896@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-use-after-free in madvise_walk_vmas+0x661/0xae0 mm/madvise.c:1726
Read of size 8 at addr ffff88803322aa08 by task syz.0.3603/14995
CPU: 1 UID: 0 PID: 14995 Comm: syz.0.3603 Tainted: G L syzkaller #0 PREEMPT(full)
Tainted: [L]=SOFTLOCKUP
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_address_description+0x55/0x1e0 mm/kasan/report.c:378
print_report+0x58/0x70 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
madvise_walk_vmas+0x661/0xae0 mm/madvise.c:1726
madvise_do_behavior+0x386/0x540 mm/madvise.c:1929
do_madvise+0x1fa/0x2e0 mm/madvise.c:2022
__do_sys_madvise mm/madvise.c:2031 [inline]
__se_sys_madvise mm/madvise.c:2029 [inline]
__x64_sys_madvise+0xa6/0xc0 mm/madvise.c:2029
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f6f8599c799
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:00007f6f8681a028 EFLAGS: 00000246 ORIG_RAX: 000000000000001c
RAX: ffffffffffffffda RBX: 00007f6f85c16090 RCX: 00007f6f8599c799
RDX: 0000000000000019 RSI: 0000000008000000 RDI: 0000200000000000
RBP: 00007f6f85a32c99 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f6f85c16128 R14: 00007f6f85c16090 R15: 00007ffd2a0e3548
</TASK>
Allocated by task 5846:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
unpoison_slab_object mm/kasan/common.c:340 [inline]
__kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4569 [inline]
slab_alloc_node mm/slub.c:4898 [inline]
kmem_cache_alloc_noprof+0x2bc/0x650 mm/slub.c:4905
vm_area_dup+0x2b/0x680 mm/vma_init.c:123
dup_mmap+0x8b1/0x1d90 mm/mmap.c:1786
dup_mm kernel/fork.c:1533 [inline]
copy_mm+0x13b/0x4a0 kernel/fork.c:1585
copy_process+0x1efd/0x4430 kernel/fork.c:2260
kernel_clone+0x26d/0x8e0 kernel/fork.c:2709
__do_sys_clone kernel/fork.c:2850 [inline]
__se_sys_clone kernel/fork.c:2834 [inline]
__x64_sys_clone+0x1b6/0x230 kernel/fork.c:2834
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 15002:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2689 [inline]
slab_free_after_rcu_debug+0x12a/0x220 mm/slub.c:6304
rcu_do_batch kernel/rcu/tree.c:2617 [inline]
rcu_core+0x7cd/0x1070 kernel/rcu/tree.c:2869
handle_softirqs+0x22a/0x840 kernel/softirq.c:622
do_softirq+0x76/0xd0 kernel/softirq.c:523
__local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450
lock_sock include/net/sock.h:1713 [inline]
packet_do_bind+0x33/0xe10 net/packet/af_packet.c:3198
__sys_bind_socket net/socket.c:1932 [inline]
__sys_bind+0x2e3/0x410 net/socket.c:1963
__do_sys_bind net/socket.c:1968 [inline]
__se_sys_bind net/socket.c:1966 [inline]
__x64_sys_bind+0x7a/0x90 net/socket.c:1966
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Last potentially related work creation:
kasan_save_stack+0x3e/0x60 mm/kasan/common.c:57
kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:556
slab_free_hook mm/slub.c:2650 [inline]
slab_free mm/slub.c:6242 [inline]
kmem_cache_free+0x44f/0x650 mm/slub.c:6369
remove_vma mm/vma.c:473 [inline]
vms_complete_munmap_vmas+0x929/0xc60 mm/vma.c:1361
do_vmi_align_munmap+0x3b7/0x4b0 mm/vma.c:1604
do_vmi_munmap+0x252/0x2d0 mm/vma.c:1652
do_munmap+0xf9/0x170 mm/mmap.c:1067
mremap_to+0x353/0x880 mm/mremap.c:1448
do_mremap mm/mremap.c:1999 [inline]
__do_sys_mremap mm/mremap.c:2055 [inline]
__se_sys_mremap+0xe6d/0x11d0 mm/mremap.c:2023
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff88803322aa00
which belongs to the cache vm_area_struct of size 256
The buggy address is located 8 bytes inside of
freed 256-byte region [ffff88803322aa00, ffff88803322ab00)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88803322adc0 pfn:0x3322a
memcg:ffff88803322af01
flags: 0xfff00000000200(workingset|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000200 ffff88801c294b40 ffffea0001163f90 ffffea0001dba810
raw: ffff88803322adc0 00000008000c000b 00000000f5000000 ffff88803322af01
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 11045, tgid 11045 (syz.0.2085), ts 233915893282, free_ts 233883108694
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x231/0x280 mm/page_alloc.c:1850
prep_new_page mm/page_alloc.c:1858 [inline]
get_page_from_freelist+0x24ba/0x2540 mm/page_alloc.c:3938
__alloc_frozen_pages_noprof+0x233/0x3d0 mm/page_alloc.c:5218
alloc_slab_page mm/slub.c:3278 [inline]
allocate_slab+0x77/0x660 mm/slub.c:3467
new_slab mm/slub.c:3525 [inline]
refill_objects+0x339/0x3d0 mm/slub.c:7247
refill_sheaf mm/slub.c:2816 [inline]
__pcs_replace_empty_main+0x321/0x720 mm/slub.c:4651
alloc_from_pcs mm/slub.c:4749 [inline]
slab_alloc_node mm/slub.c:4883 [inline]
kmem_cache_alloc_noprof+0x37d/0x650 mm/slub.c:4905
vm_area_dup+0x2b/0x680 mm/vma_init.c:123
__split_vma+0x1dc/0xa40 mm/vma.c:516
split_vma mm/vma.c:599 [inline]
vma_modify+0x88a/0x1e10 mm/vma.c:1691
vma_modify_flags+0x24b/0x330 mm/vma.c:1719
mprotect_fixup+0x62a/0xb60 mm/mprotect.c:759
do_mprotect_pkey+0x8d5/0xd20 mm/mprotect.c:937
__do_sys_mprotect mm/mprotect.c:958 [inline]
__se_sys_mprotect mm/mprotect.c:955 [inline]
__x64_sys_mprotect+0x80/0x90 mm/mprotect.c:955
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 23 tgid 23 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1394 [inline]
__free_frozen_pages+0xbc7/0xd30 mm/page_alloc.c:2935
__tlb_remove_table_free mm/mmu_gather.c:228 [inline]
tlb_remove_table_rcu+0x85/0x100 mm/mmu_gather.c:291
rcu_do_batch kernel/rcu/tree.c:2617 [inline]
rcu_core+0x7cd/0x1070 kernel/rcu/tree.c:2869
handle_softirqs+0x22a/0x840 kernel/softirq.c:622
run_ksoftirqd+0x36/0x60 kernel/softirq.c:1076
smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Memory state around the buggy address:
ffff88803322a900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88803322a980: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
>ffff88803322aa00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88803322aa80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88803322ab00: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
==================================================================
---
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 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in madvise_walk_vmas
2026-03-31 9:07 [syzbot] [mm?] KASAN: slab-use-after-free Read in madvise_walk_vmas syzbot
@ 2026-03-31 10:52 ` Lorenzo Stoakes (Oracle)
2026-03-31 11:43 ` Lorenzo Stoakes (Oracle)
1 sibling, 0 replies; 4+ messages in thread
From: Lorenzo Stoakes (Oracle) @ 2026-03-31 10:52 UTC (permalink / raw)
To: syzbot
Cc: Liam.Howlett, akpm, david, jannh, linux-kernel, linux-mm,
syzkaller-bugs, vbabka
On Tue, Mar 31, 2026 at 02:07:28AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: e77a5a5cfe43 Add linux-next specific files for 20260326
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13640f52580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=51ca7cbda5f81780
> dashboard link: https://syzkaller.appspot.com/bug?extid=001b9efd14d3e8fac896
> compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/63883a48e879/disk-e77a5a5c.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/cfdff9b548ab/vmlinux-e77a5a5c.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/f2e4eca37d44/bzImage-e77a5a5c.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+001b9efd14d3e8fac896@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KASAN: slab-use-after-free in madvise_walk_vmas+0x661/0xae0 mm/madvise.c:1726
Thanks, this is code from a patch of mine so taking a look.
> Read of size 8 at addr ffff88803322aa08 by task syz.0.3603/14995
>
> CPU: 1 UID: 0 PID: 14995 Comm: syz.0.3603 Tainted: G L syzkaller #0 PREEMPT(full)
> Tainted: [L]=SOFTLOCKUP
> 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_address_description+0x55/0x1e0 mm/kasan/report.c:378
> print_report+0x58/0x70 mm/kasan/report.c:482
> kasan_report+0x117/0x150 mm/kasan/report.c:595
> madvise_walk_vmas+0x661/0xae0 mm/madvise.c:1726
> madvise_do_behavior+0x386/0x540 mm/madvise.c:1929
> do_madvise+0x1fa/0x2e0 mm/madvise.c:2022
> __do_sys_madvise mm/madvise.c:2031 [inline]
> __se_sys_madvise mm/madvise.c:2029 [inline]
> __x64_sys_madvise+0xa6/0xc0 mm/madvise.c:2029
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f6f8599c799
> 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:00007f6f8681a028 EFLAGS: 00000246 ORIG_RAX: 000000000000001c
> RAX: ffffffffffffffda RBX: 00007f6f85c16090 RCX: 00007f6f8599c799
> RDX: 0000000000000019 RSI: 0000000008000000 RDI: 0000200000000000
> RBP: 00007f6f85a32c99 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007f6f85c16128 R14: 00007f6f85c16090 R15: 00007ffd2a0e3548
> </TASK>
>
> Allocated by task 5846:
> kasan_save_stack mm/kasan/common.c:57 [inline]
> kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
> unpoison_slab_object mm/kasan/common.c:340 [inline]
> __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
> kasan_slab_alloc include/linux/kasan.h:253 [inline]
> slab_post_alloc_hook mm/slub.c:4569 [inline]
> slab_alloc_node mm/slub.c:4898 [inline]
> kmem_cache_alloc_noprof+0x2bc/0x650 mm/slub.c:4905
> vm_area_dup+0x2b/0x680 mm/vma_init.c:123
> dup_mmap+0x8b1/0x1d90 mm/mmap.c:1786
> dup_mm kernel/fork.c:1533 [inline]
> copy_mm+0x13b/0x4a0 kernel/fork.c:1585
> copy_process+0x1efd/0x4430 kernel/fork.c:2260
> kernel_clone+0x26d/0x8e0 kernel/fork.c:2709
> __do_sys_clone kernel/fork.c:2850 [inline]
> __se_sys_clone kernel/fork.c:2834 [inline]
> __x64_sys_clone+0x1b6/0x230 kernel/fork.c:2834
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Freed by task 15002:
> kasan_save_stack mm/kasan/common.c:57 [inline]
> kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
> kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
> poison_slab_object mm/kasan/common.c:253 [inline]
> __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
> kasan_slab_free include/linux/kasan.h:235 [inline]
> slab_free_hook mm/slub.c:2689 [inline]
> slab_free_after_rcu_debug+0x12a/0x220 mm/slub.c:6304
> rcu_do_batch kernel/rcu/tree.c:2617 [inline]
> rcu_core+0x7cd/0x1070 kernel/rcu/tree.c:2869
> handle_softirqs+0x22a/0x840 kernel/softirq.c:622
> do_softirq+0x76/0xd0 kernel/softirq.c:523
> __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450
> lock_sock include/net/sock.h:1713 [inline]
> packet_do_bind+0x33/0xe10 net/packet/af_packet.c:3198
> __sys_bind_socket net/socket.c:1932 [inline]
> __sys_bind+0x2e3/0x410 net/socket.c:1963
> __do_sys_bind net/socket.c:1968 [inline]
> __se_sys_bind net/socket.c:1966 [inline]
> __x64_sys_bind+0x7a/0x90 net/socket.c:1966
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Last potentially related work creation:
> kasan_save_stack+0x3e/0x60 mm/kasan/common.c:57
> kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:556
> slab_free_hook mm/slub.c:2650 [inline]
> slab_free mm/slub.c:6242 [inline]
> kmem_cache_free+0x44f/0x650 mm/slub.c:6369
> remove_vma mm/vma.c:473 [inline]
> vms_complete_munmap_vmas+0x929/0xc60 mm/vma.c:1361
> do_vmi_align_munmap+0x3b7/0x4b0 mm/vma.c:1604
> do_vmi_munmap+0x252/0x2d0 mm/vma.c:1652
> do_munmap+0xf9/0x170 mm/mmap.c:1067
> mremap_to+0x353/0x880 mm/mremap.c:1448
> do_mremap mm/mremap.c:1999 [inline]
> __do_sys_mremap mm/mremap.c:2055 [inline]
> __se_sys_mremap+0xe6d/0x11d0 mm/mremap.c:2023
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> The buggy address belongs to the object at ffff88803322aa00
> which belongs to the cache vm_area_struct of size 256
> The buggy address is located 8 bytes inside of
> freed 256-byte region [ffff88803322aa00, ffff88803322ab00)
>
> The buggy address belongs to the physical page:
> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88803322adc0 pfn:0x3322a
> memcg:ffff88803322af01
> flags: 0xfff00000000200(workingset|node=0|zone=1|lastcpupid=0x7ff)
> page_type: f5(slab)
> raw: 00fff00000000200 ffff88801c294b40 ffffea0001163f90 ffffea0001dba810
> raw: ffff88803322adc0 00000008000c000b 00000000f5000000 ffff88803322af01
> page dumped because: kasan: bad access detected
> page_owner tracks the page as allocated
> page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 11045, tgid 11045 (syz.0.2085), ts 233915893282, free_ts 233883108694
> set_page_owner include/linux/page_owner.h:32 [inline]
> post_alloc_hook+0x231/0x280 mm/page_alloc.c:1850
> prep_new_page mm/page_alloc.c:1858 [inline]
> get_page_from_freelist+0x24ba/0x2540 mm/page_alloc.c:3938
> __alloc_frozen_pages_noprof+0x233/0x3d0 mm/page_alloc.c:5218
> alloc_slab_page mm/slub.c:3278 [inline]
> allocate_slab+0x77/0x660 mm/slub.c:3467
> new_slab mm/slub.c:3525 [inline]
> refill_objects+0x339/0x3d0 mm/slub.c:7247
> refill_sheaf mm/slub.c:2816 [inline]
> __pcs_replace_empty_main+0x321/0x720 mm/slub.c:4651
> alloc_from_pcs mm/slub.c:4749 [inline]
> slab_alloc_node mm/slub.c:4883 [inline]
> kmem_cache_alloc_noprof+0x37d/0x650 mm/slub.c:4905
> vm_area_dup+0x2b/0x680 mm/vma_init.c:123
> __split_vma+0x1dc/0xa40 mm/vma.c:516
> split_vma mm/vma.c:599 [inline]
> vma_modify+0x88a/0x1e10 mm/vma.c:1691
> vma_modify_flags+0x24b/0x330 mm/vma.c:1719
> mprotect_fixup+0x62a/0xb60 mm/mprotect.c:759
> do_mprotect_pkey+0x8d5/0xd20 mm/mprotect.c:937
> __do_sys_mprotect mm/mprotect.c:958 [inline]
> __se_sys_mprotect mm/mprotect.c:955 [inline]
> __x64_sys_mprotect+0x80/0x90 mm/mprotect.c:955
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> page last free pid 23 tgid 23 stack trace:
> reset_page_owner include/linux/page_owner.h:25 [inline]
> __free_pages_prepare mm/page_alloc.c:1394 [inline]
> __free_frozen_pages+0xbc7/0xd30 mm/page_alloc.c:2935
> __tlb_remove_table_free mm/mmu_gather.c:228 [inline]
> tlb_remove_table_rcu+0x85/0x100 mm/mmu_gather.c:291
> rcu_do_batch kernel/rcu/tree.c:2617 [inline]
> rcu_core+0x7cd/0x1070 kernel/rcu/tree.c:2869
> handle_softirqs+0x22a/0x840 kernel/softirq.c:622
> run_ksoftirqd+0x36/0x60 kernel/softirq.c:1076
> smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
> kthread+0x388/0x470 kernel/kthread.c:436
> ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
>
> Memory state around the buggy address:
> ffff88803322a900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff88803322a980: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
> >ffff88803322aa00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff88803322aa80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff88803322ab00: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
> ==================================================================
>
>
> ---
> 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 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in madvise_walk_vmas
2026-03-31 9:07 [syzbot] [mm?] KASAN: slab-use-after-free Read in madvise_walk_vmas syzbot
2026-03-31 10:52 ` Lorenzo Stoakes (Oracle)
@ 2026-03-31 11:43 ` Lorenzo Stoakes (Oracle)
2026-03-31 11:54 ` Lorenzo Stoakes (Oracle)
1 sibling, 1 reply; 4+ messages in thread
From: Lorenzo Stoakes (Oracle) @ 2026-03-31 11:43 UTC (permalink / raw)
To: syzbot
Cc: Liam.Howlett, akpm, david, jannh, linux-kernel, linux-mm,
syzkaller-bugs, vbabka
On Tue, Mar 31, 2026 at 02:07:28AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: e77a5a5cfe43 Add linux-next specific files for 20260326
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13640f52580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=51ca7cbda5f81780
> dashboard link: https://syzkaller.appspot.com/bug?extid=001b9efd14d3e8fac896
> compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/63883a48e879/disk-e77a5a5c.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/cfdff9b548ab/vmlinux-e77a5a5c.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/f2e4eca37d44/bzImage-e77a5a5c.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+001b9efd14d3e8fac896@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KASAN: slab-use-after-free in madvise_walk_vmas+0x661/0xae0 mm/madvise.c:1726
This is:
if (vma && range->end < vma->vm_end) <-- 1726
range->end = vma->vm_end;
> Read of size 8 at addr ffff88803322aa08 by task syz.0.3603/14995
It'd make no sense for a UAF on stack variable range, so it's vma->vm_end
(offset lines up).
So it means we have a stale vma pointer here in madvise_walk_vmas():
error = madvise_vma_behavior(madv_behavior);
if (error)
return error;
if (madv_behavior->lock_dropped) { <--- this is a big clue
/* We dropped the mmap lock, we can't ref the VMA. */
prev = NULL;
vma = NULL;
madv_behavior->lock_dropped = false;
} else {
vma = madv_behavior->vma;
prev = vma;
}
if (vma && range->end < vma->vm_end)
range->end = vma->vm_end;
So _after_ the madvise_vma_behavior() call, we won't look at a vma if the lock
was dropped.
So perhaps we're not correctly propagating this + then getting a stale VMA pointer...
(See below for analysis from registers as to why this is MADV_COLLAPSE)
In madvise_colapse(), we pass the lock_dropped parameter to
collapse_single_pmd(), which can then set the pointed-to boolean to true.
But then it refreshes the vma via hugepage_vma_revalidate on the next iteration:
for (addr = hstart; addr < hend; addr += HPAGE_PMD_SIZE) {
enum scan_result result = SCAN_FAIL;
if (*lock_dropped) {
...
mmap_read_lock(mm);
*lock_dropped = false;
result = hugepage_vma_revalidate(mm, addr, false, &vma,
cc);
...
}
result = collapse_single_pmd(addr, vma, lock_dropped, cc);
...
}
And something might have raced to change what that VMA is.
However... coming back to madvise_walk_vmas():
if (madv_behavior->lock_dropped) {
...
} else {
vma = madv_behavior->vma; <-- we are reading a stale VMA...
prev = vma; <-- ...and even assigning it to prev!
}
This whole 'lock dropped' notion is somewhat horrible... I guess it's really
about detecting a gap in VMAs, which is not exactly crucial since we tolerate
there being gaps (but return -ENOMEM for some reason to signify it).
Anyway, the proximate fix here is for *lock_dropped in madvise_collapse() to
actually be relative to whether the lock _was every dropped_ not whether it
currently is... which is of course what the meaning always was, it's just that
commit e24d552a17e9 ("mm/madvise: eliminate very confusing manipulation of prev
VMA") messed this up.
I'll send a fix.
Cheers, Lorenzo
>
> CPU: 1 UID: 0 PID: 14995 Comm: syz.0.3603 Tainted: G L syzkaller #0 PREEMPT(full)
> Tainted: [L]=SOFTLOCKUP
> 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_address_description+0x55/0x1e0 mm/kasan/report.c:378
> print_report+0x58/0x70 mm/kasan/report.c:482
> kasan_report+0x117/0x150 mm/kasan/report.c:595
> madvise_walk_vmas+0x661/0xae0 mm/madvise.c:1726
> madvise_do_behavior+0x386/0x540 mm/madvise.c:1929
> do_madvise+0x1fa/0x2e0 mm/madvise.c:2022
> __do_sys_madvise mm/madvise.c:2031 [inline]
> __se_sys_madvise mm/madvise.c:2029 [inline]
> __x64_sys_madvise+0xa6/0xc0 mm/madvise.c:2029
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f6f8599c799
> 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:00007f6f8681a028 EFLAGS: 00000246 ORIG_RAX: 000000000000001c
> RAX: ffffffffffffffda RBX: 00007f6f85c16090 RCX: 00007f6f8599c799
> RDX: 0000000000000019 RSI: 0000000008000000 RDI: 0000200000000000
Clearly an madvise() is being performed, x86-64 syscall convention is RDI, RSI, RDX etc.
madvise(addr, size, advice) so 3rd param = advice = 0x19 = MADV_COLLAPSE.
> RBP: 00007f6f85a32c99 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007f6f85c16128 R14: 00007f6f85c16090 R15: 00007ffd2a0e3548
> </TASK>
>
> Allocated by task 5846:
> kasan_save_stack mm/kasan/common.c:57 [inline]
> kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
> unpoison_slab_object mm/kasan/common.c:340 [inline]
> __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
> kasan_slab_alloc include/linux/kasan.h:253 [inline]
> slab_post_alloc_hook mm/slub.c:4569 [inline]
> slab_alloc_node mm/slub.c:4898 [inline]
> kmem_cache_alloc_noprof+0x2bc/0x650 mm/slub.c:4905
> vm_area_dup+0x2b/0x680 mm/vma_init.c:123
> dup_mmap+0x8b1/0x1d90 mm/mmap.c:1786
> dup_mm kernel/fork.c:1533 [inline]
> copy_mm+0x13b/0x4a0 kernel/fork.c:1585
> copy_process+0x1efd/0x4430 kernel/fork.c:2260
> kernel_clone+0x26d/0x8e0 kernel/fork.c:2709
> __do_sys_clone kernel/fork.c:2850 [inline]
> __se_sys_clone kernel/fork.c:2834 [inline]
> __x64_sys_clone+0x1b6/0x230 kernel/fork.c:2834
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Freed by task 15002:
> kasan_save_stack mm/kasan/common.c:57 [inline]
> kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
> kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
> poison_slab_object mm/kasan/common.c:253 [inline]
> __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
> kasan_slab_free include/linux/kasan.h:235 [inline]
> slab_free_hook mm/slub.c:2689 [inline]
> slab_free_after_rcu_debug+0x12a/0x220 mm/slub.c:6304
> rcu_do_batch kernel/rcu/tree.c:2617 [inline]
> rcu_core+0x7cd/0x1070 kernel/rcu/tree.c:2869
> handle_softirqs+0x22a/0x840 kernel/softirq.c:622
> do_softirq+0x76/0xd0 kernel/softirq.c:523
> __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450
> lock_sock include/net/sock.h:1713 [inline]
> packet_do_bind+0x33/0xe10 net/packet/af_packet.c:3198
> __sys_bind_socket net/socket.c:1932 [inline]
> __sys_bind+0x2e3/0x410 net/socket.c:1963
> __do_sys_bind net/socket.c:1968 [inline]
> __se_sys_bind net/socket.c:1966 [inline]
> __x64_sys_bind+0x7a/0x90 net/socket.c:1966
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Last potentially related work creation:
> kasan_save_stack+0x3e/0x60 mm/kasan/common.c:57
> kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:556
> slab_free_hook mm/slub.c:2650 [inline]
> slab_free mm/slub.c:6242 [inline]
> kmem_cache_free+0x44f/0x650 mm/slub.c:6369
> remove_vma mm/vma.c:473 [inline]
> vms_complete_munmap_vmas+0x929/0xc60 mm/vma.c:1361
> do_vmi_align_munmap+0x3b7/0x4b0 mm/vma.c:1604
> do_vmi_munmap+0x252/0x2d0 mm/vma.c:1652
> do_munmap+0xf9/0x170 mm/mmap.c:1067
> mremap_to+0x353/0x880 mm/mremap.c:1448
> do_mremap mm/mremap.c:1999 [inline]
> __do_sys_mremap mm/mremap.c:2055 [inline]
> __se_sys_mremap+0xe6d/0x11d0 mm/mremap.c:2023
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> The buggy address belongs to the object at ffff88803322aa00
> which belongs to the cache vm_area_struct of size 256
> The buggy address is located 8 bytes inside of
> freed 256-byte region [ffff88803322aa00, ffff88803322ab00)
>
> The buggy address belongs to the physical page:
> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88803322adc0 pfn:0x3322a
> memcg:ffff88803322af01
> flags: 0xfff00000000200(workingset|node=0|zone=1|lastcpupid=0x7ff)
> page_type: f5(slab)
> raw: 00fff00000000200 ffff88801c294b40 ffffea0001163f90 ffffea0001dba810
> raw: ffff88803322adc0 00000008000c000b 00000000f5000000 ffff88803322af01
> page dumped because: kasan: bad access detected
> page_owner tracks the page as allocated
> page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 11045, tgid 11045 (syz.0.2085), ts 233915893282, free_ts 233883108694
> set_page_owner include/linux/page_owner.h:32 [inline]
> post_alloc_hook+0x231/0x280 mm/page_alloc.c:1850
> prep_new_page mm/page_alloc.c:1858 [inline]
> get_page_from_freelist+0x24ba/0x2540 mm/page_alloc.c:3938
> __alloc_frozen_pages_noprof+0x233/0x3d0 mm/page_alloc.c:5218
> alloc_slab_page mm/slub.c:3278 [inline]
> allocate_slab+0x77/0x660 mm/slub.c:3467
> new_slab mm/slub.c:3525 [inline]
> refill_objects+0x339/0x3d0 mm/slub.c:7247
> refill_sheaf mm/slub.c:2816 [inline]
> __pcs_replace_empty_main+0x321/0x720 mm/slub.c:4651
> alloc_from_pcs mm/slub.c:4749 [inline]
> slab_alloc_node mm/slub.c:4883 [inline]
> kmem_cache_alloc_noprof+0x37d/0x650 mm/slub.c:4905
> vm_area_dup+0x2b/0x680 mm/vma_init.c:123
> __split_vma+0x1dc/0xa40 mm/vma.c:516
> split_vma mm/vma.c:599 [inline]
> vma_modify+0x88a/0x1e10 mm/vma.c:1691
> vma_modify_flags+0x24b/0x330 mm/vma.c:1719
> mprotect_fixup+0x62a/0xb60 mm/mprotect.c:759
> do_mprotect_pkey+0x8d5/0xd20 mm/mprotect.c:937
> __do_sys_mprotect mm/mprotect.c:958 [inline]
> __se_sys_mprotect mm/mprotect.c:955 [inline]
> __x64_sys_mprotect+0x80/0x90 mm/mprotect.c:955
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> page last free pid 23 tgid 23 stack trace:
> reset_page_owner include/linux/page_owner.h:25 [inline]
> __free_pages_prepare mm/page_alloc.c:1394 [inline]
> __free_frozen_pages+0xbc7/0xd30 mm/page_alloc.c:2935
> __tlb_remove_table_free mm/mmu_gather.c:228 [inline]
> tlb_remove_table_rcu+0x85/0x100 mm/mmu_gather.c:291
> rcu_do_batch kernel/rcu/tree.c:2617 [inline]
> rcu_core+0x7cd/0x1070 kernel/rcu/tree.c:2869
> handle_softirqs+0x22a/0x840 kernel/softirq.c:622
> run_ksoftirqd+0x36/0x60 kernel/softirq.c:1076
> smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
> kthread+0x388/0x470 kernel/kthread.c:436
> ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
>
> Memory state around the buggy address:
> ffff88803322a900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff88803322a980: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
> >ffff88803322aa00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff88803322aa80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff88803322ab00: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
> ==================================================================
>
>
> ---
> 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 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in madvise_walk_vmas
2026-03-31 11:43 ` Lorenzo Stoakes (Oracle)
@ 2026-03-31 11:54 ` Lorenzo Stoakes (Oracle)
0 siblings, 0 replies; 4+ messages in thread
From: Lorenzo Stoakes (Oracle) @ 2026-03-31 11:54 UTC (permalink / raw)
To: syzbot
Cc: Liam.Howlett, akpm, david, jannh, linux-kernel, linux-mm,
syzkaller-bugs, vbabka
On Tue, Mar 31, 2026 at 12:43:32PM +0100, Lorenzo Stoakes (Oracle) wrote:
> On Tue, Mar 31, 2026 at 02:07:28AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: e77a5a5cfe43 Add linux-next specific files for 20260326
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=13640f52580000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=51ca7cbda5f81780
> > dashboard link: https://syzkaller.appspot.com/bug?extid=001b9efd14d3e8fac896
> > compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/63883a48e879/disk-e77a5a5c.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/cfdff9b548ab/vmlinux-e77a5a5c.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/f2e4eca37d44/bzImage-e77a5a5c.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+001b9efd14d3e8fac896@syzkaller.appspotmail.com
> >
> > ==================================================================
> > BUG: KASAN: slab-use-after-free in madvise_walk_vmas+0x661/0xae0 mm/madvise.c:1726
>
> This is:
>
> if (vma && range->end < vma->vm_end) <-- 1726
> range->end = vma->vm_end;
>
> > Read of size 8 at addr ffff88803322aa08 by task syz.0.3603/14995
>
> It'd make no sense for a UAF on stack variable range, so it's vma->vm_end
> (offset lines up).
>
> So it means we have a stale vma pointer here in madvise_walk_vmas():
>
> error = madvise_vma_behavior(madv_behavior);
> if (error)
> return error;
> if (madv_behavior->lock_dropped) { <--- this is a big clue
> /* We dropped the mmap lock, we can't ref the VMA. */
> prev = NULL;
> vma = NULL;
> madv_behavior->lock_dropped = false;
> } else {
> vma = madv_behavior->vma;
> prev = vma;
> }
>
> if (vma && range->end < vma->vm_end)
> range->end = vma->vm_end;
>
> So _after_ the madvise_vma_behavior() call, we won't look at a vma if the lock
> was dropped.
>
> So perhaps we're not correctly propagating this + then getting a stale VMA pointer...
>
> (See below for analysis from registers as to why this is MADV_COLLAPSE)
>
> In madvise_colapse(), we pass the lock_dropped parameter to
> collapse_single_pmd(), which can then set the pointed-to boolean to true.
>
> But then it refreshes the vma via hugepage_vma_revalidate on the next iteration:
>
> for (addr = hstart; addr < hend; addr += HPAGE_PMD_SIZE) {
> enum scan_result result = SCAN_FAIL;
>
> if (*lock_dropped) {
> ...
> mmap_read_lock(mm);
> *lock_dropped = false;
> result = hugepage_vma_revalidate(mm, addr, false, &vma,
> cc);
> ...
> }
>
> result = collapse_single_pmd(addr, vma, lock_dropped, cc);
>
> ...
> }
>
> And something might have raced to change what that VMA is.
>
> However... coming back to madvise_walk_vmas():
>
> if (madv_behavior->lock_dropped) {
> ...
> } else {
> vma = madv_behavior->vma; <-- we are reading a stale VMA...
> prev = vma; <-- ...and even assigning it to prev!
> }
>
> This whole 'lock dropped' notion is somewhat horrible... I guess it's really
> about detecting a gap in VMAs, which is not exactly crucial since we tolerate
> there being gaps (but return -ENOMEM for some reason to signify it).
>
> Anyway, the proximate fix here is for *lock_dropped in madvise_collapse() to
> actually be relative to whether the lock _was every dropped_ not whether it
> currently is... which is of course what the meaning always was, it's just that
> commit e24d552a17e9 ("mm/madvise: eliminate very confusing manipulation of prev
> VMA") messed this up.
>
> I'll send a fix.
Actually looks to be Nico's series - mm/khugepaged: unify khugepaged and
madv_collapse with collapse_single_pmd() - that has the bug. Replying there.
Cheers, Lorenzo
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-03-31 11:54 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-31 9:07 [syzbot] [mm?] KASAN: slab-use-after-free Read in madvise_walk_vmas syzbot
2026-03-31 10:52 ` Lorenzo Stoakes (Oracle)
2026-03-31 11:43 ` Lorenzo Stoakes (Oracle)
2026-03-31 11:54 ` Lorenzo Stoakes (Oracle)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox