[syzbot] [mm?] [f2fs?] [exfat?] memory leak in __kfree_rcu_sheaf

[syzbot] [mm?] [f2fs?] [exfat?] memory leak in __kfree_rcu_sheaf

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    e7aa57247700 Merge tag 'spi-fix-v6.19-rc8' of git://git.ke..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=122ae7fa580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=9d7d0fbecb37bff8
dashboard link: https://syzkaller.appspot.com/bug?extid=cae7809e9dc1459e4e63
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=130e2944580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/28d29c9b5ae2/disk-e7aa5724.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/0683244c7a0f/vmlinux-e7aa5724.xz
kernel image: https://storage.googleapis.com/syzbot-assets/cd8cc5cb8b94/bzImage-e7aa5724.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/f78f58e821b0/mount_0.gz
  fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=10f7165a580000)

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

BUG: memory leak
unreferenced object 0xffff888113218600 (size 512):
  comm "sed", pid 6046, jiffies 4294945902
  hex dump (first 32 bytes):
    00 8e 13 29 81 88 ff ff 00 12 86 27 81 88 ff ff  ...).......'....
    00 5a 04 00 81 88 ff ff 00 00 00 00 00 00 00 00  .Z..............
  backtrace (crc 49909e19):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4958 [inline]
    slab_alloc_node mm/slub.c:5263 [inline]
    __do_kmalloc_node mm/slub.c:5656 [inline]
    __kmalloc_noprof+0x465/0x680 mm/slub.c:5669
    kmalloc_noprof include/linux/slab.h:961 [inline]
    kzalloc_noprof include/linux/slab.h:1094 [inline]
    alloc_empty_sheaf+0x36/0x50 mm/slub.c:2618
    __kfree_rcu_sheaf+0x155/0x210 mm/slub.c:6304
    kfree_rcu_sheaf mm/slab_common.c:1631 [inline]
    kvfree_call_rcu+0x202/0x3d0 mm/slab_common.c:1981
    ma_free_rcu lib/maple_tree.c:208 [inline]
    ma_free_rcu+0x29/0x40 lib/maple_tree.c:205
    mas_free lib/maple_tree.c:1174 [inline]
    mas_replace_node lib/maple_tree.c:1581 [inline]
    mas_wr_node_store+0x5fc/0x730 lib/maple_tree.c:3553
    mas_wr_store_entry+0x4eb/0x760 lib/maple_tree.c:3764
    mas_store_prealloc+0x358/0x740 lib/maple_tree.c:5169
    vma_iter_store_overwrite mm/vma.h:544 [inline]
    commit_merge+0x28e/0x490 mm/vma.c:763
    vma_expand+0x264/0x460 mm/vma.c:1200
    vma_merge_new_range+0xe3/0x350 mm/vma.c:1099
    __mmap_region+0x54b/0x15b0 mm/vma.c:2747
    mmap_region+0xfb/0x1e0 mm/vma.c:2830
    do_mmap+0x7ac/0xb80 mm/mmap.c:558
    vm_mmap_pgoff+0x1a6/0x2d0 mm/util.c:581
    ksys_mmap_pgoff+0x233/0x2d0 mm/mmap.c:604

BUG: memory leak
unreferenced object 0xffff888127861200 (size 512):
  comm "udevd", pid 6236, jiffies 4294948784
  hex dump (first 32 bytes):
    00 86 21 13 81 88 ff ff 18 e0 05 00 81 88 ff ff  ..!.............
    00 5a 04 00 81 88 ff ff 00 00 00 00 00 00 00 00  .Z..............
  backtrace (crc 5b72581e):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4958 [inline]
    slab_alloc_node mm/slub.c:5263 [inline]
    __do_kmalloc_node mm/slub.c:5656 [inline]
    __kmalloc_noprof+0x465/0x680 mm/slub.c:5669
    kmalloc_noprof include/linux/slab.h:961 [inline]
    kzalloc_noprof include/linux/slab.h:1094 [inline]
    alloc_empty_sheaf+0x36/0x50 mm/slub.c:2618
    __kfree_rcu_sheaf+0x155/0x210 mm/slub.c:6304
    kfree_rcu_sheaf mm/slab_common.c:1631 [inline]
    kvfree_call_rcu+0x202/0x3d0 mm/slab_common.c:1981
    ma_free_rcu lib/maple_tree.c:208 [inline]
    ma_free_rcu+0x29/0x40 lib/maple_tree.c:205
    mas_topiary_node lib/maple_tree.c:2311 [inline]
    mas_topiary_node lib/maple_tree.c:2299 [inline]
    mas_topiary_replace+0xb0f/0x1400 lib/maple_tree.c:2410
    mas_wmb_replace lib/maple_tree.c:2433 [inline]
    mas_spanning_rebalance+0x14e1/0x24b0 lib/maple_tree.c:2738
    mas_wr_spanning_store+0x983/0x10d0 lib/maple_tree.c:3479
    mas_wr_store_entry+0x4d5/0x760 lib/maple_tree.c:3767
    mas_store_gfp+0x341/0x640 lib/maple_tree.c:5138
    vma_iter_clear_gfp include/linux/mm.h:1141 [inline]
    do_vmi_align_munmap+0x259/0x2d0 mm/vma.c:1574
    do_vmi_munmap+0x17c/0x280 mm/vma.c:1627
    __vm_munmap+0xec/0x200 mm/vma.c:3247
    __do_sys_munmap mm/mmap.c:1077 [inline]
    __se_sys_munmap mm/mmap.c:1074 [inline]
    __x64_sys_munmap+0x1f/0x30 mm/mmap.c:1074
    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
    do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94
    entry_SYSCALL_64_after_hwframe+0x77/0x7f

BUG: memory leak
unreferenced object 0xffff88812c458000 (size 4480):
  comm "udevd", pid 5181, jiffies 4294950983
  hex dump (first 32 bytes):
    01 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00  ................
  backtrace (crc ad4af9e6):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4958 [inline]
    slab_alloc_node mm/slub.c:5263 [inline]
    kmem_cache_alloc_node_noprof+0x422/0x590 mm/slub.c:5315
    alloc_task_struct_node kernel/fork.c:184 [inline]
    dup_task_struct kernel/fork.c:915 [inline]
    copy_process+0x286/0x2870 kernel/fork.c:2052
    kernel_clone+0xac/0x6e0 kernel/fork.c:2651
    __do_sys_clone+0x7f/0xb0 kernel/fork.c:2792
    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
    do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94
    entry_SYSCALL_64_after_hwframe+0x77/0x7f

BUG: memory leak
unreferenced object 0xffff8881274a1540 (size 184):
  comm "udevd", pid 5181, jiffies 4294950983
  hex dump (first 32 bytes):
    02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 54e589bc):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4958 [inline]
    slab_alloc_node mm/slub.c:5263 [inline]
    kmem_cache_alloc_noprof+0x412/0x580 mm/slub.c:5270
    prepare_creds+0x22/0x600 kernel/cred.c:185
    copy_creds+0x44/0x290 kernel/cred.c:286
    copy_process+0x7a7/0x2870 kernel/fork.c:2086
    kernel_clone+0xac/0x6e0 kernel/fork.c:2651
    __do_sys_clone+0x7f/0xb0 kernel/fork.c:2792
    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
    do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94
    entry_SYSCALL_64_after_hwframe+0x77/0x7f

BUG: memory leak
unreferenced object 0xffff888109639020 (size 32):
  comm "udevd", pid 5181, jiffies 4294950983
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    f8 52 86 00 81 88 ff ff 00 00 00 00 00 00 00 00  .R..............
  backtrace (crc 336e1c5f):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4958 [inline]
    slab_alloc_node mm/slub.c:5263 [inline]
    __do_kmalloc_node mm/slub.c:5656 [inline]
    __kmalloc_noprof+0x465/0x680 mm/slub.c:5669
    kmalloc_noprof include/linux/slab.h:961 [inline]
    kzalloc_noprof include/linux/slab.h:1094 [inline]
    lsm_blob_alloc+0x4d/0x80 security/security.c:192
    lsm_cred_alloc security/security.c:209 [inline]
    security_prepare_creds+0x2d/0x290 security/security.c:2763
    prepare_creds+0x395/0x600 kernel/cred.c:215
    copy_creds+0x44/0x290 kernel/cred.c:286
    copy_process+0x7a7/0x2870 kernel/fork.c:2086
    kernel_clone+0xac/0x6e0 kernel/fork.c:2651
    __do_sys_clone+0x7f/0xb0 kernel/fork.c:2792
    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
    do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94
    entry_SYSCALL_64_after_hwframe+0x77/0x7f

BUG: memory leak
unreferenced object 0xffff888126fdbd80 (size 64):
  comm "udevd", pid 5181, jiffies 4294950983
  hex dump (first 32 bytes):
    c0 c3 4e 46 81 88 ff ff 00 00 00 00 00 00 00 00  ..NF............
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 508a43e4):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4958 [inline]
    slab_alloc_node mm/slub.c:5263 [inline]
    __do_kmalloc_node mm/slub.c:5656 [inline]
    __kmalloc_noprof+0x465/0x680 mm/slub.c:5669
    kmalloc_noprof include/linux/slab.h:961 [inline]
    kzalloc_noprof include/linux/slab.h:1094 [inline]
    lsm_blob_alloc+0x4d/0x80 security/security.c:192
    lsm_task_alloc security/security.c:244 [inline]
    security_task_alloc+0x2a/0x260 security/security.c:2682
    copy_process+0xf07/0x2870 kernel/fork.c:2203
    kernel_clone+0xac/0x6e0 kernel/fork.c:2651
    __do_sys_clone+0x7f/0xb0 kernel/fork.c:2792
    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
    do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94
    entry_SYSCALL_64_after_hwframe+0x77/0x7f

connection error: failed to recv *flatrpc.ExecutorMessageRawT: EOF


---
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

Re: [syzbot] [mm?] [f2fs?] [exfat?] memory leak in __kfree_rcu_sheaf

[Qing Wang]

#syz test

diff --git a/mm/slub.c b/mm/slub.c
index cdc1e652ec52..387979b89120 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -6307,15 +6307,21 @@ bool __kfree_rcu_sheaf(struct kmem_cache *s, void *obj)
 			goto fail;
 
 		if (!local_trylock(&s->cpu_sheaves->lock)) {
-			barn_put_empty_sheaf(barn, empty);
+			if (barn && data_race(barn->nr_empty) < MAX_EMPTY_SHEAVES)
+				barn_put_empty_sheaf(barn, empty);
+			else
+				free_empty_sheaf(s, empty);
 			goto fail;
 		}
 
 		pcs = this_cpu_ptr(s->cpu_sheaves);
 
-		if (unlikely(pcs->rcu_free))
-			barn_put_empty_sheaf(barn, empty);
-		else
+		if (unlikely(pcs->rcu_free)) {
+			if (barn && data_race(barn->nr_empty) < MAX_EMPTY_SHEAVES)
+				barn_put_empty_sheaf(barn, empty);
+			else
+				free_empty_sheaf(s, empty);
+		} else
 			pcs->rcu_free = empty;
 	}
 

Re: [syzbot] [mm?] [f2fs?] [exfat?] memory leak in __kfree_rcu_sheaf

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
memory leak in __pcs_replace_empty_main

BUG: memory leak
unreferenced object 0xffff88810005fa00 (size 512):
  comm "swapper/0", pid 0, jiffies 4294937296
  hex dump (first 32 bytes):
    00 2e c5 05 81 88 ff ff 00 a2 96 0a 81 88 ff ff  ................
    00 12 04 00 81 88 ff ff 3c 00 00 00 00 00 00 00  ........<.......
  backtrace (crc ee49fed0):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4520 [inline]
    slab_alloc_node mm/slub.c:4844 [inline]
    __do_kmalloc_node mm/slub.c:5237 [inline]
    __kmalloc_noprof+0x3bd/0x560 mm/slub.c:5250
    kmalloc_noprof include/linux/slab.h:954 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    __alloc_empty_sheaf+0x35/0x50 mm/slub.c:2771
    alloc_empty_sheaf mm/slub.c:2786 [inline]
    alloc_full_sheaf mm/slub.c:2834 [inline]
    __pcs_replace_empty_main+0x1e4/0x260 mm/slub.c:4602
    alloc_from_pcs mm/slub.c:4695 [inline]
    slab_alloc_node mm/slub.c:4829 [inline]
    __kmalloc_cache_noprof+0x3ac/0x480 mm/slub.c:5353
    kmalloc_noprof include/linux/slab.h:950 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    __irq_domain_alloc_fwnode+0x37/0x140 kernel/irq/irqdomain.c:95
    irq_domain_alloc_named_fwnode include/linux/irqdomain.h:271 [inline]
    arch_early_irq_init+0x1c/0x70 arch/x86/kernel/apic/vector.c:803
    start_kernel+0x931/0xb80 init/main.c:1114
    x86_64_start_reservations+0x24/0x30 arch/x86/kernel/head64.c:310
    x86_64_start_kernel+0xce/0xd0 arch/x86/kernel/head64.c:291
    common_startup_64+0x13e/0x148

BUG: memory leak
unreferenced object 0xffff8881008f8c00 (size 512):
  comm "kthreadd", pid 2, jiffies 4294937339
  hex dump (first 32 bytes):
    00 d6 04 00 81 88 ff ff 00 92 96 0a 81 88 ff ff  ................
    00 12 04 00 81 88 ff ff 3c 00 00 00 00 00 00 00  ........<.......
  backtrace (crc f2ef5290):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4520 [inline]
    slab_alloc_node mm/slub.c:4844 [inline]
    __do_kmalloc_node mm/slub.c:5237 [inline]
    __kmalloc_noprof+0x3bd/0x560 mm/slub.c:5250
    kmalloc_noprof include/linux/slab.h:954 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    __alloc_empty_sheaf+0x35/0x50 mm/slub.c:2771
    alloc_empty_sheaf mm/slub.c:2786 [inline]
    alloc_full_sheaf mm/slub.c:2834 [inline]
    __pcs_replace_empty_main+0x1e4/0x260 mm/slub.c:4602
    alloc_from_pcs mm/slub.c:4695 [inline]
    slab_alloc_node mm/slub.c:4829 [inline]
    __kmalloc_cache_node_noprof+0x3ef/0x4e0 mm/slub.c:5366
    kmalloc_node_noprof include/linux/slab.h:1077 [inline]
    __get_vm_area_node+0xc6/0x1d0 mm/vmalloc.c:3221
    __vmalloc_node_range_noprof+0x1d3/0xe50 mm/vmalloc.c:4024
    __vmalloc_node_noprof+0x71/0x90 mm/vmalloc.c:4124
    alloc_thread_stack_node kernel/fork.c:355 [inline]
    dup_task_struct kernel/fork.c:924 [inline]
    copy_process+0x3e5/0x28c0 kernel/fork.c:2050
    kernel_clone+0xac/0x6e0 kernel/fork.c:2654
    kernel_thread+0x80/0xb0 kernel/fork.c:2715
    create_kthread kernel/kthread.c:490 [inline]
    kthreadd+0x186/0x250 kernel/kthread.c:848
    ret_from_fork+0x23c/0x4b0 arch/x86/kernel/process.c:158
    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

BUG: memory leak
unreferenced object 0xffff888105c53200 (size 512):
  comm "kworker/1:0", pid 23, jiffies 4294937917
  hex dump (first 32 bytes):
    00 a2 96 0a 81 88 ff ff 00 d4 04 00 81 88 ff ff  ................
    00 12 04 00 81 88 ff ff 3c 00 00 00 00 00 00 00  ........<.......
  backtrace (crc d24dd055):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4520 [inline]
    slab_alloc_node mm/slub.c:4844 [inline]
    __do_kmalloc_node mm/slub.c:5237 [inline]
    __kmalloc_noprof+0x3bd/0x560 mm/slub.c:5250
    kmalloc_noprof include/linux/slab.h:954 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    __alloc_empty_sheaf+0x35/0x50 mm/slub.c:2771
    alloc_empty_sheaf mm/slub.c:2786 [inline]
    __pcs_replace_full_main+0xe9/0x2c0 mm/slub.c:5700
    free_to_pcs mm/slub.c:5753 [inline]
    slab_free mm/slub.c:6154 [inline]
    kfree+0x352/0x390 mm/slub.c:6467
    vfree.part.0+0x1d5/0x4d0 mm/vmalloc.c:3485
    vfree mm/vmalloc.c:3456 [inline]
    delayed_vfree_work+0x5b/0x90 mm/vmalloc.c:3398
    process_one_work+0x26c/0x5d0 kernel/workqueue.c:3275
    process_scheduled_works kernel/workqueue.c:3358 [inline]
    worker_thread+0x243/0x490 kernel/workqueue.c:3439
    kthread+0x14e/0x1a0 kernel/kthread.c:467
    ret_from_fork+0x23c/0x4b0 arch/x86/kernel/process.c:158
    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

BUG: memory leak
unreferenced object 0xffff888105c52e00 (size 512):
  comm "kworker/u8:5", pid 4440, jiffies 4294937918
  hex dump (first 32 bytes):
    c8 2c 04 00 81 88 ff ff 00 fa 05 00 81 88 ff ff  .,..............
    00 12 04 00 81 88 ff ff 3c 00 00 00 00 00 00 00  ........<.......
  backtrace (crc a68b63de):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4520 [inline]
    slab_alloc_node mm/slub.c:4844 [inline]
    __do_kmalloc_node mm/slub.c:5237 [inline]
    __kmalloc_noprof+0x3bd/0x560 mm/slub.c:5250
    kmalloc_noprof include/linux/slab.h:954 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    __alloc_empty_sheaf+0x35/0x50 mm/slub.c:2771
    alloc_empty_sheaf mm/slub.c:2786 [inline]
    __pcs_replace_full_main+0xe9/0x2c0 mm/slub.c:5700
    free_to_pcs mm/slub.c:5753 [inline]
    slab_free mm/slub.c:6154 [inline]
    kfree+0x352/0x390 mm/slub.c:6467
    call_usermodehelper_freeinfo kernel/umh.c:43 [inline]
    umh_complete kernel/umh.c:57 [inline]
    call_usermodehelper_exec_async+0x1c7/0x1f0 kernel/umh.c:119
    ret_from_fork+0x23c/0x4b0 arch/x86/kernel/process.c:158
    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

BUG: memory leak
unreferenced object 0xffff88810a96a200 (size 512):
  comm "udevadm", pid 5177, jiffies 4294938175
  hex dump (first 32 bytes):
    00 fa 05 00 81 88 ff ff 00 32 c5 05 81 88 ff ff  .........2......
    00 12 04 00 81 88 ff ff 3c 00 00 00 00 00 00 00  ........<.......
  backtrace (crc 94107438):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4520 [inline]
    slab_alloc_node mm/slub.c:4844 [inline]
    __do_kmalloc_node mm/slub.c:5237 [inline]
    __kmalloc_noprof+0x3bd/0x560 mm/slub.c:5250
    kmalloc_noprof include/linux/slab.h:954 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    __alloc_empty_sheaf+0x35/0x50 mm/slub.c:2771
    alloc_empty_sheaf mm/slub.c:2786 [inline]
    alloc_full_sheaf mm/slub.c:2834 [inline]
    __pcs_replace_empty_main+0x1e4/0x260 mm/slub.c:4602
    alloc_from_pcs mm/slub.c:4695 [inline]
    slab_alloc_node mm/slub.c:4829 [inline]
    __kmalloc_cache_noprof+0x3ac/0x480 mm/slub.c:5353
    kmalloc_noprof include/linux/slab.h:950 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    kernfs_get_open_node fs/kernfs/file.c:543 [inline]
    kernfs_fop_open+0x4f3/0x580 fs/kernfs/file.c:718
    do_dentry_open+0x202/0x8d0 fs/open.c:949
    vfs_open+0x3d/0x1b0 fs/open.c:1081
    do_open fs/namei.c:4671 [inline]
    path_openat+0x154d/0x1e20 fs/namei.c:4830
    do_file_open+0x121/0x200 fs/namei.c:4859
    do_sys_openat2+0xa5/0x140 fs/open.c:1366
    do_sys_open fs/open.c:1372 [inline]
    __do_sys_openat fs/open.c:1388 [inline]
    __se_sys_openat fs/open.c:1383 [inline]
    __x64_sys_openat+0x82/0xf0 fs/open.c:1383
    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
    do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94
    entry_SYSCALL_64_after_hwframe+0x77/0x7f

BUG: memory leak
unreferenced object 0xffff888109d58400 (size 512):
  comm "udevd", pid 5176, jiffies 4294938222
  hex dump (first 32 bytes):
    00 12 47 2a 81 88 ff ff 00 ee 46 2a 81 88 ff ff  ..G*......F*....
    00 12 04 00 81 88 ff ff 00 00 00 00 00 00 00 00  ................
  backtrace (crc af8b5cec):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4520 [inline]
    slab_alloc_node mm/slub.c:4844 [inline]
    __do_kmalloc_node mm/slub.c:5237 [inline]
    __kmalloc_noprof+0x3bd/0x560 mm/slub.c:5250
    kmalloc_noprof include/linux/slab.h:954 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    __alloc_empty_sheaf+0x35/0x50 mm/slub.c:2771
    alloc_empty_sheaf mm/slub.c:2786 [inline]
    __kfree_rcu_sheaf+0x164/0x240 mm/slub.c:5887
    kfree_rcu_sheaf mm/slab_common.c:1608 [inline]
    kvfree_call_rcu+0x1f6/0x3c0 mm/slab_common.c:1957
    kernfs_unlink_open_file+0x194/0x1b0 fs/kernfs/file.c:604
    kernfs_fop_release+0x55/0x110 fs/kernfs/file.c:783
    __fput+0x1b5/0x4f0 fs/file_table.c:469
    fput_close_sync+0x67/0x120 fs/file_table.c:574
    __do_sys_close fs/open.c:1509 [inline]
    __se_sys_close fs/open.c:1494 [inline]
    __x64_sys_close+0x4a/0xc0 fs/open.c:1494
    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
    do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94
    entry_SYSCALL_64_after_hwframe+0x77/0x7f

connection error: failed to recv *flatrpc.ExecutorMessageRawT: EOF


Tested on:

commit:         11439c46 Linux 7.0-rc2
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1277a202580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=2c6ad6fefffa76b1
dashboard link: https://syzkaller.appspot.com/bug?extid=cae7809e9dc1459e4e63
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=13801006580000

Re: [syzbot] [mm?] [f2fs?] [exfat?] memory leak in __kfree_rcu_sheaf

[Vlastimil Babka (SUSE)]

On 3/2/26 04:41, Qing Wang wrote:
> #syz test
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index cdc1e652ec52..387979b89120 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -6307,15 +6307,21 @@ bool __kfree_rcu_sheaf(struct kmem_cache *s, void *obj)
>  			goto fail;
>  
>  		if (!local_trylock(&s->cpu_sheaves->lock)) {
> -			barn_put_empty_sheaf(barn, empty);
> +			if (barn && data_race(barn->nr_empty) < MAX_EMPTY_SHEAVES)
> +				barn_put_empty_sheaf(barn, empty);
> +			else
> +				free_empty_sheaf(s, empty);
>  			goto fail;
>  		}
>  
>  		pcs = this_cpu_ptr(s->cpu_sheaves);
>  
> -		if (unlikely(pcs->rcu_free))
> -			barn_put_empty_sheaf(barn, empty);
> -		else
> +		if (unlikely(pcs->rcu_free)) {
> +			if (barn && data_race(barn->nr_empty) < MAX_EMPTY_SHEAVES)
> +				barn_put_empty_sheaf(barn, empty);
> +			else
> +				free_empty_sheaf(s, empty);
> +		} else
>  			pcs->rcu_free = empty;
>  	}

I don't think this would fix any leak, and syzbot agrees. It would limit the
empty sheaves in barn more strictly, but they are not leaked.
Hm I don't see any leak in __kfree_rcu_sheaf() or rcu_free_sheaf(). Wonder
if kmemleak lacks visibility into barns or pcs's as roots for searching what
objects are considered referenced, or something?

Re: [syzbot] [mm?] [f2fs?] [exfat?] memory leak in __kfree_rcu_sheaf

[Harry Yoo]

[+Cc adding Catalin for kmemleak bits]

On Mon, Mar 02, 2026 at 09:39:48AM +0100, Vlastimil Babka (SUSE) wrote:
> On 3/2/26 04:41, Qing Wang wrote:
> > #syz test
> > 
> > diff --git a/mm/slub.c b/mm/slub.c
> > index cdc1e652ec52..387979b89120 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -6307,15 +6307,21 @@ bool __kfree_rcu_sheaf(struct kmem_cache *s, void *obj)
> >  			goto fail;
> >  
> >  		if (!local_trylock(&s->cpu_sheaves->lock)) {
> > -			barn_put_empty_sheaf(barn, empty);
> > +			if (barn && data_race(barn->nr_empty) < MAX_EMPTY_SHEAVES)
> > +				barn_put_empty_sheaf(barn, empty);
> > +			else
> > +				free_empty_sheaf(s, empty);
> >  			goto fail;
> >  		}
> >  
> >  		pcs = this_cpu_ptr(s->cpu_sheaves);
> >  
> > -		if (unlikely(pcs->rcu_free))
> > -			barn_put_empty_sheaf(barn, empty);
> > -		else
> > +		if (unlikely(pcs->rcu_free)) {
> > +			if (barn && data_race(barn->nr_empty) < MAX_EMPTY_SHEAVES)
> > +				barn_put_empty_sheaf(barn, empty);
> > +			else
> > +				free_empty_sheaf(s, empty);
> > +		} else
> >  			pcs->rcu_free = empty;
> >  	}
> 
> I don't think this would fix any leak, and syzbot agrees. It would limit the
> empty sheaves in barn more strictly, but they are not leaked.
> Hm I don't see any leak in __kfree_rcu_sheaf() or rcu_free_sheaf(). Wonder
> if kmemleak lacks visibility into barns or pcs's as roots for searching what
> objects are considered referenced, or something?

Objects that are allocated from slab and percpu allocator should be
properly tracked by kmemleak. But those allocated with
gfpflags_allow_spinning() == false are not tracked by kmemleak.

When barns and sheaves are allocated early (!gfpflags_allow_spinning()
due to gfp_allowed_mask) and it skips kmemleak_alloc_recursive(), 
it could produce false positives because from kmemleak's point of view,
the objects are not reachable from the root set (data section, stack,
etc.).

To me it seems kmemleak should gain allow_spin == false support
sooner or later.

-- 
Cheers,
Harry / Hyeonggon

Re: [syzbot] [mm?] [f2fs?] [exfat?] memory leak in __kfree_rcu_sheaf

[Vlastimil Babka (SUSE)]

On 3/4/26 2:30 AM, Harry Yoo wrote:
> [+Cc adding Catalin for kmemleak bits]
> 
> On Mon, Mar 02, 2026 at 09:39:48AM +0100, Vlastimil Babka (SUSE) wrote:
>> On 3/2/26 04:41, Qing Wang wrote:
>>> #syz test
>>>
>>> diff --git a/mm/slub.c b/mm/slub.c
>>> index cdc1e652ec52..387979b89120 100644
>>> --- a/mm/slub.c
>>> +++ b/mm/slub.c
>>> @@ -6307,15 +6307,21 @@ bool __kfree_rcu_sheaf(struct kmem_cache *s, void *obj)
>>>  			goto fail;
>>>  
>>>  		if (!local_trylock(&s->cpu_sheaves->lock)) {
>>> -			barn_put_empty_sheaf(barn, empty);
>>> +			if (barn && data_race(barn->nr_empty) < MAX_EMPTY_SHEAVES)
>>> +				barn_put_empty_sheaf(barn, empty);
>>> +			else
>>> +				free_empty_sheaf(s, empty);
>>>  			goto fail;
>>>  		}
>>>  
>>>  		pcs = this_cpu_ptr(s->cpu_sheaves);
>>>  
>>> -		if (unlikely(pcs->rcu_free))
>>> -			barn_put_empty_sheaf(barn, empty);
>>> -		else
>>> +		if (unlikely(pcs->rcu_free)) {
>>> +			if (barn && data_race(barn->nr_empty) < MAX_EMPTY_SHEAVES)
>>> +				barn_put_empty_sheaf(barn, empty);
>>> +			else
>>> +				free_empty_sheaf(s, empty);
>>> +		} else
>>>  			pcs->rcu_free = empty;
>>>  	}
>>
>> I don't think this would fix any leak, and syzbot agrees. It would limit the
>> empty sheaves in barn more strictly, but they are not leaked.
>> Hm I don't see any leak in __kfree_rcu_sheaf() or rcu_free_sheaf(). Wonder
>> if kmemleak lacks visibility into barns or pcs's as roots for searching what
>> objects are considered referenced, or something?
> 
> Objects that are allocated from slab and percpu allocator should be
> properly tracked by kmemleak. But those allocated with
> gfpflags_allow_spinning() == false are not tracked by kmemleak.
> 
> When barns and sheaves are allocated early (!gfpflags_allow_spinning()
> due to gfp_allowed_mask) and it skips kmemleak_alloc_recursive(), 
> it could produce false positives because from kmemleak's point of view,
> the objects are not reachable from the root set (data section, stack,
> etc.).

Good point.

> To me it seems kmemleak should gain allow_spin == false support
> sooner or later.

Or we figure out how to deal with the false allow_spin == false during
boot. Here I'm a bit confused how exactly it happens because AFAICS in
slub we apply gfp_allowed_mask only when allocating a new slab, and in
slab_post_alloc_hook() we apply it to init_mask. That is indeed passed
to kmemleak_alloc_recursive() but not used for the
gfpflags_allow_spinning() decision. kmemleak_alloc_recursive() should
succeed because nobody should be holding any locks that would require
spinning.

Unless it's some interaction with deferred pages like the one fixed by
commit fd3634312a04f33?

Re: [syzbot] [mm?] [f2fs?] [exfat?] memory leak in __kfree_rcu_sheaf

[Catalin Marinas]

On Wed, Mar 04, 2026 at 02:39:47PM +0100, Vlastimil Babka (SUSE) wrote:
> On 3/4/26 2:30 AM, Harry Yoo wrote:
> > [+Cc adding Catalin for kmemleak bits]
> > On Mon, Mar 02, 2026 at 09:39:48AM +0100, Vlastimil Babka (SUSE) wrote:
> >> On 3/2/26 04:41, Qing Wang wrote:
> >>> #syz test
> >>>
> >>> diff --git a/mm/slub.c b/mm/slub.c
> >>> index cdc1e652ec52..387979b89120 100644
> >>> --- a/mm/slub.c
> >>> +++ b/mm/slub.c
> >>> @@ -6307,15 +6307,21 @@ bool __kfree_rcu_sheaf(struct kmem_cache *s, void *obj)
> >>>  			goto fail;
> >>>  
> >>>  		if (!local_trylock(&s->cpu_sheaves->lock)) {
> >>> -			barn_put_empty_sheaf(barn, empty);
> >>> +			if (barn && data_race(barn->nr_empty) < MAX_EMPTY_SHEAVES)
> >>> +				barn_put_empty_sheaf(barn, empty);
> >>> +			else
> >>> +				free_empty_sheaf(s, empty);
> >>>  			goto fail;
> >>>  		}
> >>>  
> >>>  		pcs = this_cpu_ptr(s->cpu_sheaves);
> >>>  
> >>> -		if (unlikely(pcs->rcu_free))
> >>> -			barn_put_empty_sheaf(barn, empty);
> >>> -		else
> >>> +		if (unlikely(pcs->rcu_free)) {
> >>> +			if (barn && data_race(barn->nr_empty) < MAX_EMPTY_SHEAVES)
> >>> +				barn_put_empty_sheaf(barn, empty);
> >>> +			else
> >>> +				free_empty_sheaf(s, empty);
> >>> +		} else
> >>>  			pcs->rcu_free = empty;
> >>>  	}
> >>
> >> I don't think this would fix any leak, and syzbot agrees. It would limit the
> >> empty sheaves in barn more strictly, but they are not leaked.
> >> Hm I don't see any leak in __kfree_rcu_sheaf() or rcu_free_sheaf(). Wonder
> >> if kmemleak lacks visibility into barns or pcs's as roots for searching what
> >> objects are considered referenced, or something?
> > 
> > Objects that are allocated from slab and percpu allocator should be
> > properly tracked by kmemleak. But those allocated with
> > gfpflags_allow_spinning() == false are not tracked by kmemleak.
> > 
> > When barns and sheaves are allocated early (!gfpflags_allow_spinning()
> > due to gfp_allowed_mask) and it skips kmemleak_alloc_recursive(), 
> > it could produce false positives because from kmemleak's point of view,
> > the objects are not reachable from the root set (data section, stack,
> > etc.).
> 
> Good point.
> 
> > To me it seems kmemleak should gain allow_spin == false support
> > sooner or later.
> 
> Or we figure out how to deal with the false allow_spin == false during
> boot. Here I'm a bit confused how exactly it happens because AFAICS in
> slub we apply gfp_allowed_mask only when allocating a new slab, and in
> slab_post_alloc_hook() we apply it to init_mask. That is indeed passed
> to kmemleak_alloc_recursive() but not used for the
> gfpflags_allow_spinning() decision. kmemleak_alloc_recursive() should
> succeed because nobody should be holding any locks that would require
> spinning.

I don't fully understand what goes on. If kmemleak_alloc_recursive()
failed to allocate for some reason (other than SLAB_NOLEAKTRACE), it
would loudly disable kmemleak altogether and stop reporting leaks. Also
kmemleak doesn't care about allow_spin, it's only the slub code which
avoids calling kmemleak if spinning not allowed (as it takes some locks,
may call back into the slab allocator).

I wonder whether some early kmem_cache_node allocations like the ones in
early_kmem_cache_node_alloc() are not tracked and then kmemleak cannot
find n->barn. I got lost in the slub code, but something like this:

-----------8<-----------------------------------
diff --git a/mm/slub.c b/mm/slub.c
index 0c906fefc31b..401557ff5487 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -7513,6 +7513,7 @@ static void early_kmem_cache_node_alloc(int node)
 	slab->freelist = get_freepointer(kmem_cache_node, n);
 	slab->inuse = 1;
 	kmem_cache_node->node[node] = n;
+	kmemleak_alloc(n, sizeof(*n), 1, GFP_NOWAIT);
 	init_kmem_cache_node(n, NULL);
 	inc_slabs_node(kmem_cache_node, node, slab->objects);
 
-------------8<----------------------------------------

Another thing I noticed, not sure it's related but we should probably
ignore an object once it has been passed to kvfree_call_rcu(), similar
to what we do on the main path in this function. Also see commit
5f98fd034ca6 ("rcu: kmemleak: Ignore kmemleak false positives when
RCU-freeing objects") when we added this kmemleak_ignore().

---------8<-----------------------------------
diff --git a/mm/slab_common.c b/mm/slab_common.c
index d5a70a831a2a..73f4668d870d 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1954,8 +1954,14 @@ void kvfree_call_rcu(struct rcu_head *head, void *ptr)
 	if (!head)
 		might_sleep();
 
-	if (!IS_ENABLED(CONFIG_PREEMPT_RT) && kfree_rcu_sheaf(ptr))
+	if (!IS_ENABLED(CONFIG_PREEMPT_RT) && kfree_rcu_sheaf(ptr)) {
+		/*
+		 * The object is now queued for deferred freeing via an RCU
+		 * sheaf. Tell kmemleak to ignore it.
+		 */
+		kmemleak_ignore(ptr);
 		return;
+	}
 
 	// Queue the object but don't yet schedule the batch.
 	if (debug_rcu_head_queue(ptr)) {
----------------8<-----------------------------------

-- 
Catalin