KASAN: stack-out-of-bounds Read in umh_complete

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 591cd61541b9 Add linux-next specific files for 20221207
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1341475b880000
kernel config: https://syzkaller.appspot.com/x/.config?x=8b2d3e63e054c24f
dashboard link: https://syzkaller.appspot.com/bug?extid=c92c6a251d49ceceb625
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
CC: [linux-...@vger.kernel.org lu...@kernel.org pet...@infradead.org tg...@linutronix.de]

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

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/bc862c01ec56/disk-591cd615.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/8f9b93f8ed2f/vmlinux-591cd615.xz
kernel image: https://storage.googleapis.com/syzbot-assets/9d5cb636d548/bzImage-591cd615.xz

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

==================================================================
BUG: KASAN: stack-out-of-bounds in __lock_acquire+0x3ee7/0x56d0 kernel/locking/lockdep.c:4925
Read of size 8 at addr ffffc90015d2fb28 by task kworker/u4:15/5325

CPU: 0 PID: 5325 Comm: kworker/u4:15 Not tainted 6.1.0-rc8-next-20221207-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: events_unbound call_usermodehelper_exec_work
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:306 [inline]
print_report+0x15e/0x45d mm/kasan/report.c:417
kasan_report+0xbf/0x1f0 mm/kasan/report.c:517
__lock_acquire+0x3ee7/0x56d0 kernel/locking/lockdep.c:4925
lock_acquire kernel/locking/lockdep.c:5668 [inline]
lock_acquire+0x1e3/0x630 kernel/locking/lockdep.c:5633
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x3d/0x60 kernel/locking/spinlock.c:162
complete+0x1d/0x1f0 kernel/sched/completion.c:32
umh_complete+0x32/0x90 kernel/umh.c:59
call_usermodehelper_exec_sync kernel/umh.c:144 [inline]
call_usermodehelper_exec_work+0x115/0x180 kernel/umh.c:167
process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
worker_thread+0x669/0x1090 kernel/workqueue.c:2436
kthread+0x2e8/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
</TASK>

The buggy address belongs to the virtual mapping at
[ffffc90015d28000, ffffc90015d31000) created by:
kernel_clone+0xeb/0xa40 kernel/fork.c:2681

The buggy address belongs to the physical page:
page:ffffea00008eaf80 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x23abe
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000000 0000000000000000 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x102dc2(GFP_HIGHUSER|__GFP_NOWARN|__GFP_ZERO), pid 4645, tgid 4645 (dhcpcd), ts 742840406177, free_ts 741827386172
prep_new_page mm/page_alloc.c:2531 [inline]
get_page_from_freelist+0x119c/0x2ce0 mm/page_alloc.c:4283
__alloc_pages+0x1cb/0x5b0 mm/page_alloc.c:5549
alloc_pages+0x1aa/0x270 mm/mempolicy.c:2285
vm_area_alloc_pages mm/vmalloc.c:2989 [inline]
__vmalloc_area_node mm/vmalloc.c:3057 [inline]
__vmalloc_node_range+0x978/0x13c0 mm/vmalloc.c:3227
alloc_thread_stack_node kernel/fork.c:311 [inline]
dup_task_struct kernel/fork.c:987 [inline]
copy_process+0x12d2/0x75c0 kernel/fork.c:2097
kernel_clone+0xeb/0xa40 kernel/fork.c:2681
__do_sys_clone+0xba/0x100 kernel/fork.c:2822
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
page last free stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]
free_pages_prepare mm/page_alloc.c:1446 [inline]
free_pcp_prepare+0x65c/0xc00 mm/page_alloc.c:1496
free_unref_page_prepare mm/page_alloc.c:3369 [inline]
free_unref_page_list+0x176/0xcd0 mm/page_alloc.c:3510
release_pages+0xcb1/0x1330 mm/swap.c:1076
tlb_batch_pages_flush+0xa8/0x1a0 mm/mmu_gather.c:93
tlb_flush_mmu_free mm/mmu_gather.c:288 [inline]
tlb_flush_mmu mm/mmu_gather.c:295 [inline]
tlb_finish_mmu+0x14b/0x7e0 mm/mmu_gather.c:387
exit_mmap+0x202/0x7b0 mm/mmap.c:3096
__mmput+0x128/0x4c0 kernel/fork.c:1207
mmput+0x60/0x70 kernel/fork.c:1229
exit_mm kernel/exit.c:563 [inline]
do_exit+0x9ac/0x2950 kernel/exit.c:854
do_group_exit+0xd4/0x2a0 kernel/exit.c:1010
get_signal+0x21c3/0x2450 kernel/signal.c:2859
arch_do_signal_or_restart+0x79/0x5c0 arch/x86/kernel/signal.c:306
exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203
__syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x63/0xcd

Memory state around the buggy address:
ffffc90015d2fa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffc90015d2fa80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffc90015d2fb00: 00 00 f1 f1 f1 f1 00 00 f2 f2 00 00 00 f3 f3 f3
^
ffffc90015d2fb80: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffc90015d2fc00: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 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 syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

[syzbot]

Auto-closing this bug as obsolete.
Crashes did not happen for a while, no reproducer and no activity.