[syzbot] [bpf?] KASAN: invalid-free in drain_mem_cache

From: syzbot
Date: Tue Jul 08 2025 - 09:47:00 EST

Next message: Sebastian Andrzej Siewior: "Re: [PATCH 2/3] futex: Use RCU-based per-CPU reference counting instead of rcuref_t"
Previous message: Gregory CLEMENT: "[PATCH v3 2/2] MIPS: CPS: Optimise delay CPU calibration for SMP"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hello,

syzbot found the following issue on:

HEAD commit: 17bbde2e1716 Merge tag 'net-6.16-rc5' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13924582580000
kernel config: https://syzkaller.appspot.com/x/.config?x=3f6ddf055b5c86f8
dashboard link: https://syzkaller.appspot.com/bug?extid=6fe5045b85546171744e
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/0fb40d3b9565/disk-17bbde2e.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/ae187eb465df/vmlinux-17bbde2e.xz
kernel image: https://storage.googleapis.com/syzbot-assets/108daf226325/bzImage-17bbde2e.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+6fe5045b85546171744e@xxxxxxxxxxxxxxxxxxxxxxxxx

==================================================================
BUG: KASAN: invalid-free in free_one kernel/bpf/memalloc.c:260 [inline]
BUG: KASAN: invalid-free in free_all kernel/bpf/memalloc.c:269 [inline]
BUG: KASAN: invalid-free in drain_mem_cache+0x1d8/0x480 kernel/bpf/memalloc.c:640
Free of addr ffff888044850001 by task kworker/u8:2/36

CPU: 0 UID: 0 PID: 36 Comm: kworker/u8:2 Not tainted 6.16.0-rc4-syzkaller-00108-g17bbde2e1716 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Workqueue: events_unbound bpf_map_free_deferred
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:408 [inline]
print_report+0xd2/0x2b0 mm/kasan/report.c:521
kasan_report_invalid_free+0xea/0x110 mm/kasan/report.c:596
kasan_kfree_large include/linux/kasan.h:241 [inline]
free_large_kmalloc+0x8c/0x200 mm/slub.c:4762
free_one kernel/bpf/memalloc.c:260 [inline]
free_all kernel/bpf/memalloc.c:269 [inline]
drain_mem_cache+0x1d8/0x480 kernel/bpf/memalloc.c:640
bpf_mem_alloc_destroy+0x13d/0x4d0 kernel/bpf/memalloc.c:754
trie_free+0x132/0x150 kernel/bpf/lpm_trie.c:652
bpf_map_free kernel/bpf/syscall.c:862 [inline]
bpf_map_free_deferred+0xed/0x110 kernel/bpf/syscall.c:888
process_one_work kernel/workqueue.c:3238 [inline]
process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
kthread+0x711/0x8a0 kernel/kthread.c:464
ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>

The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x44850
head: order:4 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
memcg:ffff888027533f82
flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f8(unknown)
raw: 00fff00000000040 0000000000000000 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000000000 00000001f8000000 ffff888027533f82
head: 00fff00000000040 0000000000000000 dead000000000122 0000000000000000
head: 0000000000000000 0000000000000000 00000001f8000000 ffff888027533f82
head: 00fff00000000004 ffffea0001121401 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000010
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 4, migratetype Unmovable, gfp_mask 0x442dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_COMP), pid 6731, tgid 6727 (syz.1.287), ts 371750372606, free_ts 371388829185
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1704
prep_new_page mm/page_alloc.c:1712 [inline]
get_page_from_freelist+0x21d5/0x22b0 mm/page_alloc.c:3669
__alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:4959
__alloc_pages_noprof+0xa/0x30 mm/page_alloc.c:4993
__alloc_pages_node_noprof include/linux/gfp.h:284 [inline]
alloc_pages_node_noprof include/linux/gfp.h:311 [inline]
___kmalloc_large_node+0x85/0x210 mm/slub.c:4272
__kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4300
__do_kmalloc_node mm/slub.c:4316 [inline]
__kmalloc_node_noprof+0x366/0x4e0 mm/slub.c:4334
alloc_bulk+0x33b/0x530 kernel/bpf/memalloc.c:246
prefill_mem_cache kernel/bpf/memalloc.c:499 [inline]
bpf_mem_alloc_init+0x45c/0xc60 kernel/bpf/memalloc.c:546
trie_alloc+0x220/0x340 kernel/bpf/lpm_trie.c:603
map_create+0x903/0x1150 kernel/bpf/syscall.c:1477
__sys_bpf+0x67e/0x860 kernel/bpf/syscall.c:5818
__do_sys_bpf kernel/bpf/syscall.c:5943 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5941 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5941
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 5952 tgid 5952 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
free_pages_prepare mm/page_alloc.c:1248 [inline]
__free_frozen_pages+0xc65/0xe60 mm/page_alloc.c:2706
kasan_depopulate_vmalloc_pte+0x74/0xa0 mm/kasan/shadow.c:472
apply_to_pte_range mm/memory.c:3032 [inline]
apply_to_pmd_range mm/memory.c:3076 [inline]
apply_to_pud_range mm/memory.c:3112 [inline]
apply_to_p4d_range mm/memory.c:3148 [inline]
__apply_to_page_range+0xb8f/0x1380 mm/memory.c:3184
kasan_release_vmalloc+0xa2/0xd0 mm/kasan/shadow.c:593
kasan_release_vmalloc_node mm/vmalloc.c:2241 [inline]
purge_vmap_node+0x214/0x8f0 mm/vmalloc.c:2258
process_one_work kernel/workqueue.c:3238 [inline]
process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
kthread+0x711/0x8a0 kernel/kthread.c:464
ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

Memory state around the buggy address:
ffff88804484ff00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88804484ff80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff888044850000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^
ffff888044850080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff888044850100: 00 00 00 00 00 00 00 00 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@xxxxxxxxxxxxxxxx.

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

Next message: Sebastian Andrzej Siewior: "Re: [PATCH 2/3] futex: Use RCU-based per-CPU reference counting instead of rcuref_t"
Previous message: Gregory CLEMENT: "[PATCH v3 2/2] MIPS: CPS: Optimise delay CPU calibration for SMP"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]