Message-ID: <aU5dA6qq-h-0XszI@hyeyoo>
Date: Fri, 26 Dec 2025 19:01:39 +0900
From: Harry Yoo <harry.yoo@...cle.com>
To: syzbot <syzbot+5272541ccbbb14e2ec30@...kaller.appspotmail.com>
Cc: Liam.Howlett@...cle.com, akpm@...ux-foundation.org, david@...nel.org,
        jannh@...gle.com, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        lorenzo.stoakes@...cle.com, riel@...riel.com,
        syzkaller-bugs@...glegroups.com, vbabka@...e.cz
Subject: Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in
 folio_remove_rmap_ptes

On Thu, Dec 25, 2025 at 11:48:22PM -0800, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    9094662f6707 Merge tag 'ata-6.19-rc2' of git://git.kernel...
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17c4db1a580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=a11e0f726bfb6765
> dashboard link: https://syzkaller.appspot.com/bug?extid=5272541ccbbb14e2ec30
> compiler:       gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> 
> Unfortunately, I don't have any reproducer for this issue yet.
> 
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-9094662f.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/5bec9d32a91c/vmlinux-9094662f.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/3df82e1a3cec/bzImage-9094662f.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+5272541ccbbb14e2ec30@...kaller.appspotmail.com
> 
> uprobe: syz.3.982:12970 failed to unregister, leaking uprobe
> ==================================================================
> BUG: KASAN: slab-use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline]
> BUG: KASAN: slab-use-after-free in atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline]
> BUG: KASAN: slab-use-after-free in __folio_rmap_sanity_checks include/linux/rmap.h:462 [inline]
> BUG: KASAN: slab-use-after-free in __folio_remove_rmap mm/rmap.c:1663 [inline]
> BUG: KASAN: slab-use-after-free in folio_remove_rmap_ptes+0x245/0xfb0 mm/rmap.c:1779
> Read of size 4 at addr ffff88802407b1a0 by task syz.3.982/12970
> 
> CPU: 2 UID: 0 PID: 12970 Comm: syz.3.982 Not tainted syzkaller #0 PREEMPT(full) 
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
> Call Trace:
>  <TASK>
>  __dump_stack lib/dump_stack.c:94 [inline]
>  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
>  print_address_description mm/kasan/report.c:378 [inline]
>  print_report+0xcd/0x630 mm/kasan/report.c:482
>  kasan_report+0xe0/0x110 mm/kasan/report.c:595
>  check_region_inline mm/kasan/generic.c:194 [inline]
>  kasan_check_range+0x100/0x1b0 mm/kasan/generic.c:200
>  instrument_atomic_read include/linux/instrumented.h:68 [inline]
>  atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline]
>  __folio_rmap_sanity_checks include/linux/rmap.h:462 [inline]

Hmm again, anon_vma with refcount == 0 was observed while unmapping a
VMA. But this time it's reported by KASAN because it's UAF. 

>  __folio_remove_rmap mm/rmap.c:1663 [inline]
>  folio_remove_rmap_ptes+0x245/0xfb0 mm/rmap.c:1779
>  zap_present_folio_ptes mm/memory.c:1650 [inline]
>  zap_present_ptes mm/memory.c:1708 [inline]
>  do_zap_pte_range mm/memory.c:1810 [inline]
>  zap_pte_range mm/memory.c:1854 [inline]
>  zap_pmd_range mm/memory.c:1946 [inline]
>  zap_pud_range mm/memory.c:1975 [inline]
>  zap_p4d_range mm/memory.c:1996 [inline]
>  unmap_page_range+0x1b7d/0x43c0 mm/memory.c:2017
>  unmap_single_vma+0x153/0x240 mm/memory.c:2059
>  unmap_vmas+0x218/0x470 mm/memory.c:2101
>  exit_mmap+0x1b0/0xb60 mm/mmap.c:1277
>  __mmput+0x12a/0x410 kernel/fork.c:1173
>  mmput+0x62/0x70 kernel/fork.c:1196
>  exit_mm kernel/exit.c:581 [inline]
>  do_exit+0x7d7/0x2bd0 kernel/exit.c:959
>  do_group_exit+0xd3/0x2a0 kernel/exit.c:1112
>  get_signal+0x2671/0x26d0 kernel/signal.c:3034
>  arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337
>  __exit_to_user_mode_loop kernel/entry/common.c:41 [inline]
>  exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75
>  __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
>  syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
>  syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]
>  syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]
>  do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f2c0938f7c9
> Code: Unable to access opcode bytes at 0x7f2c0938f79f.
> RSP: 002b:00007f2c0a231038 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
> RAX: fffffffffffffffc RBX: 00007f2c095e6090 RCX: 00007f2c0938f7c9
> RDX: 0000000000000040 RSI: 00002000000003c0 RDI: 000000000000001c
> RBP: 00007f2c09413f91 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007f2c095e6128 R14: 00007f2c095e6090 R15: 00007ffd86729c78
>  </TASK>
> 
> Allocated by task 12971:
>  kasan_save_stack+0x33/0x60 mm/kasan/common.c:56
>  kasan_save_track+0x14/0x30 mm/kasan/common.c:77
>  unpoison_slab_object mm/kasan/common.c:339 [inline]
>  __kasan_slab_alloc+0x89/0x90 mm/kasan/common.c:365
>  kasan_slab_alloc include/linux/kasan.h:252 [inline]
>  slab_post_alloc_hook mm/slub.c:4953 [inline]
>  slab_alloc_node mm/slub.c:5263 [inline]
>  kmem_cache_alloc_noprof+0x25e/0x770 mm/slub.c:5270
>  anon_vma_alloc mm/rmap.c:93 [inline]
>  __anon_vma_prepare+0x344/0x5e0 mm/rmap.c:201
>  __vmf_anon_prepare+0x11c/0x240 mm/memory.c:3673
>  vmf_anon_prepare mm/internal.h:432 [inline]
>  do_cow_fault mm/memory.c:5775 [inline]

The anon_vma was allocated during CoW fault on a private file mapping

>  do_fault+0x18b/0x1ad0 mm/memory.c:5891
>  do_pte_missing mm/memory.c:4401 [inline]
>  handle_pte_fault mm/memory.c:6273 [inline]
>  __handle_mm_fault+0x1919/0x2bb0 mm/memory.c:6411
>  handle_mm_fault+0x3fe/0xad0 mm/memory.c:6580
>  faultin_page mm/gup.c:1126 [inline]
>  __get_user_pages+0x54e/0x3590 mm/gup.c:1428
>  __get_user_pages_locked mm/gup.c:1692 [inline]
>  get_user_pages_remote+0x243/0xab0 mm/gup.c:2614
>  uprobe_write+0x22b/0x24f0 kernel/events/uprobes.c:529
>  uprobe_write_opcode+0x99/0x1a0 kernel/events/uprobes.c:493
>  set_swbp+0x112/0x200 arch/x86/kernel/uprobes.c:1090
>  install_breakpoint+0x6a4/0xa20 kernel/events/uprobes.c:1170
>  uprobe_mmap+0x512/0x10e0 kernel/events/uprobes.c:1629
>  vma_complete+0xa09/0xe80 mm/vma.c:397
>  __split_vma+0xac3/0x1050 mm/vma.c:561
>  vms_gather_munmap_vmas+0x1cb/0x1340 mm/vma.c:1362
>  __mmap_setup mm/vma.c:2366 [inline]
>  __mmap_region+0x47c/0x2a00 mm/vma.c:2690
>  mmap_region+0x1ab/0x3f0 mm/vma.c:2786
>  do_mmap+0xa3e/0x1210 mm/mmap.c:558
>  vm_mmap_pgoff+0x29e/0x470 mm/util.c:581
>  ksys_mmap_pgoff+0x32c/0x5c0 mm/mmap.c:604
>  __do_sys_mmap arch/x86/kernel/sys_x86_64.c:89 [inline]
>  __se_sys_mmap arch/x86/kernel/sys_x86_64.c:82 [inline]
>  __x64_sys_mmap+0x125/0x190 arch/x86/kernel/sys_x86_64.c:82
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> Freed by task 0:
>  kasan_save_stack+0x33/0x60 mm/kasan/common.c:56
>  kasan_save_track+0x14/0x30 mm/kasan/common.c:77
>  kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584
>  poison_slab_object mm/kasan/common.c:252 [inline]
>  __kasan_slab_free+0x5f/0x80 mm/kasan/common.c:284
>  kasan_slab_free include/linux/kasan.h:234 [inline]
>  slab_free_hook mm/slub.c:2540 [inline]
>  slab_free_after_rcu_debug+0x10c/0x300 mm/slub.c:6729
>  rcu_do_batch kernel/rcu/tree.c:2605 [inline]
>  rcu_core+0x79c/0x15f0 kernel/rcu/tree.c:2857
>  handle_softirqs+0x219/0x950 kernel/softirq.c:622
>  __do_softirq kernel/softirq.c:656 [inline]
>  invoke_softirq kernel/softirq.c:496 [inline]
>  __irq_exit_rcu+0x109/0x170 kernel/softirq.c:723
>  irq_exit_rcu+0x9/0x30 kernel/softirq.c:739
>  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline]
>  sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1056
>  asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
> 
> Last potentially related work creation:
>  kasan_save_stack+0x33/0x60 mm/kasan/common.c:56
>  kasan_record_aux_stack+0xa7/0xc0 mm/kasan/generic.c:556
>  slab_free_hook mm/slub.c:2501 [inline]
>  slab_free mm/slub.c:6670 [inline]
>  kmem_cache_free+0x15e/0x770 mm/slub.c:6781
>  anon_vma_free mm/rmap.c:136 [inline]
>  __put_anon_vma+0x114/0x3a0 mm/rmap.c:2780
>  put_anon_vma include/linux/rmap.h:117 [inline]
>  unlink_anon_vmas+0x58a/0x820 mm/rmap.c:443
>  dontunmap_complete mm/mremap.c:1265 [inline]

And then (potentially) it was freed due to MREMAP_DONTUNMAP.
If it's correct, now we know when the refcount has been dropped to zero!

In dontunmap_complete():
> if (new_vma != vrm_vma && start == old_start && end == old_end)
>        unlink_anon_vmas(vrm->vma)

It calls unlink_anon_vmas() on the old VMA if the new range is not
merged into the old VMA.

Hmm I'm having difficult time understanding how the commit 1583aa278f5
("mm: mremap: unlink anon_vmas when mremap with MREMAP_DONTUNMAP success")
is supposed to work when the new range is merged into an existing
VMA (that is not the old VMA itself).

The merge will succeed only if the other VMA doesn't have anon_vma
or it has the same anon_vma... which means we're reusing anon_vma
of the old vma, but we're calling put_anon_vma() on it?

-- 
Cheers,
Harry / Hyeonggon

>  move_vma+0x14de/0x1790 mm/mremap.c:1314
>  mremap_to+0x1b7/0x450 mm/mremap.c:1416
>  remap_move mm/mremap.c:1890 [inline]
>  do_mremap+0x13a8/0x2020 mm/mremap.c:1933
>  __do_sys_mremap+0x119/0x170 mm/mremap.c:1997
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> The buggy address belongs to the object at ffff88802407b100
>  which belongs to the cache anon_vma of size 208
> The buggy address is located 160 bytes inside of
>  freed 208-byte region [ffff88802407b100, ffff88802407b1d0)
> 
> The buggy address belongs to the physical page:
> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2407a
> head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> memcg:ffff888021c50001
> flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
> page_type: f5(slab)
> raw: 00fff00000000040 ffff88801b44dcc0 ffffea0000f7d080 dead000000000002
> raw: 0000000000000000 00000000801e001e 00000000f5000000 ffff888021c50001
> head: 00fff00000000040 ffff88801b44dcc0 ffffea0000f7d080 dead000000000002
> head: 0000000000000000 00000000801e001e 00000000f5000000 ffff888021c50001
> head: 00fff00000000001 ffffea0000901e81 00000000ffffffff 00000000ffffffff
> head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000002
> page dumped because: kasan: bad access detected
> page_owner tracks the page as allocated
> page last allocated via order 1, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 1, tgid 1 (init), ts 24478689872, free_ts 23304373426
>  set_page_owner include/linux/page_owner.h:32 [inline]
>  post_alloc_hook+0x1af/0x220 mm/page_alloc.c:1846
>  prep_new_page mm/page_alloc.c:1854 [inline]
>  get_page_from_freelist+0xd0b/0x31a0 mm/page_alloc.c:3915
>  __alloc_frozen_pages_noprof+0x25f/0x2430 mm/page_alloc.c:5210
>  alloc_pages_mpol+0x1fb/0x550 mm/mempolicy.c:2486
>  alloc_slab_page mm/slub.c:3075 [inline]
>  allocate_slab mm/slub.c:3248 [inline]
>  new_slab+0x2c3/0x430 mm/slub.c:3302
>  ___slab_alloc+0xe18/0x1c90 mm/slub.c:4656
>  __slab_alloc.constprop.0+0x63/0x110 mm/slub.c:4779
>  __slab_alloc_node mm/slub.c:4855 [inline]
>  slab_alloc_node mm/slub.c:5251 [inline]
>  kmem_cache_alloc_noprof+0x44d/0x770 mm/slub.c:5270
>  anon_vma_alloc mm/rmap.c:93 [inline]
>  __anon_vma_prepare+0x344/0x5e0 mm/rmap.c:201
>  __vmf_anon_prepare+0x11c/0x240 mm/memory.c:3673
>  vmf_anon_prepare mm/internal.h:432 [inline]
>  do_cow_fault mm/memory.c:5775 [inline]
>  do_fault+0x18b/0x1ad0 mm/memory.c:5891
>  do_pte_missing mm/memory.c:4401 [inline]
>  handle_pte_fault mm/memory.c:6273 [inline]
>  __handle_mm_fault+0x1919/0x2bb0 mm/memory.c:6411
>  handle_mm_fault+0x3fe/0xad0 mm/memory.c:6580
>  do_user_addr_fault+0x60c/0x1370 arch/x86/mm/fault.c:1336
>  handle_page_fault arch/x86/mm/fault.c:1476 [inline]
>  exc_page_fault+0x64/0xc0 arch/x86/mm/fault.c:1532
>  asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
> page last free pid 1 tgid 1 stack trace:
>  reset_page_owner include/linux/page_owner.h:25 [inline]
>  free_pages_prepare mm/page_alloc.c:1395 [inline]
>  __free_frozen_pages+0x7df/0x1170 mm/page_alloc.c:2943
>  discard_slab mm/slub.c:3346 [inline]
>  __put_partials+0x130/0x170 mm/slub.c:3886
>  qlink_free mm/kasan/quarantine.c:163 [inline]
>  qlist_free_all+0x4c/0xf0 mm/kasan/quarantine.c:179
>  kasan_quarantine_reduce+0x195/0x1e0 mm/kasan/quarantine.c:286
>  __kasan_slab_alloc+0x69/0x90 mm/kasan/common.c:349
>  kasan_slab_alloc include/linux/kasan.h:252 [inline]
>  slab_post_alloc_hook mm/slub.c:4953 [inline]
>  slab_alloc_node mm/slub.c:5263 [inline]
>  __do_kmalloc_node mm/slub.c:5656 [inline]
>  __kmalloc_node_track_caller_noprof+0x30b/0x930 mm/slub.c:5764
>  __do_krealloc mm/slub.c:7014 [inline]
>  krealloc_node_align_noprof+0xfb/0x3d0 mm/slub.c:7073
>  krealloc_array_noprof include/linux/slab.h:1034 [inline]
>  add_sysfs_param+0x19c/0xa10 kernel/params.c:663
>  kernel_add_sysfs_param kernel/params.c:812 [inline]
>  param_sysfs_builtin kernel/params.c:851 [inline]
>  param_sysfs_builtin_init+0x307/0x4c0 kernel/params.c:987
>  do_one_initcall+0x123/0x680 init/main.c:1378
>  do_initcall_level init/main.c:1440 [inline]
>  do_initcalls init/main.c:1456 [inline]
>  do_basic_setup init/main.c:1475 [inline]
>  kernel_init_freeable+0x5c8/0x920 init/main.c:1688
>  kernel_init+0x1c/0x2b0 init/main.c:1578
>  ret_from_fork+0x983/0xb10 arch/x86/kernel/process.c:158
>  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
> 
> Memory state around the buggy address:
>  ffff88802407b080: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>  ffff88802407b100: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >ffff88802407b180: fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc
>                                ^
>  ffff88802407b200: fc fc fa fb fb fb fb fb fb fb fb fb fb fb fb fb
>  ffff88802407b280: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ==================================================================
> 
> 
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ
> syzbot engineers can be reached at syzkaller@...glegroups.com.
> 
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ*status
> 
> 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

Powered by blists - more mailing lists