[moderation] [kernel?] KASAN: stack-out-of-bounds Read in vhost_task_fn

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: b5641a5d8b8b mm: don't do validate_mm() unnecessarily and ..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=126fca28a80000
kernel config: https://syzkaller.appspot.com/x/.config?x=5777fa2fceb7a2c1
dashboard link: https://syzkaller.appspot.com/bug?extid=07770b3ec3716875da84
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/3f5693fe6662/disk-b5641a5d.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/ba8bf7ac57d6/vmlinux-b5641a5d.xz
kernel image: https://storage.googleapis.com/syzbot-assets/b60a4bb56dea/bzImage-b5641a5d.xz

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

==================================================================
BUG: KASAN: stack-out-of-bounds in vhost_task_fn+0x31d/0x360 kernel/vhost_task.c:55
Read of size 8 at addr ffffc90012807e30 by task vhost-966/967

CPU: 0 PID: 967 Comm: vhost-966 Not tainted 6.4.0-syzkaller-11312-gb5641a5d8b8b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:364
print_report mm/kasan/report.c:475 [inline]
kasan_report+0x11d/0x130 mm/kasan/report.c:588
vhost_task_fn+0x31d/0x360 kernel/vhost_task.c:55
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
</TASK>

The buggy address belongs to the virtual mapping at
[ffffc90012800000, ffffc90012809000) created by:
kernel_clone+0xeb/0x890 kernel/fork.c:2911

The buggy address belongs to the physical page:
page:ffffea000206c640 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x81b19
memcg:ffff88806838d102
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
page_type: 0xffffffff()
raw: 00fff00000000000 0000000000000000 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff ffff88806838d102
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 964, tgid 964 (syz-executor.1), ts 2689909716000, free_ts 2689429092823
set_page_owner include/linux/page_owner.h:31 [inline]
post_alloc_hook+0x2db/0x350 mm/page_alloc.c:1570
prep_new_page mm/page_alloc.c:1577 [inline]
get_page_from_freelist+0xfed/0x2d30 mm/page_alloc.c:3221
__alloc_pages+0x1cb/0x4a0 mm/page_alloc.c:4477
alloc_pages+0x1aa/0x270 mm/mempolicy.c:2279
vm_area_alloc_pages mm/vmalloc.c:3059 [inline]
__vmalloc_area_node mm/vmalloc.c:3135 [inline]
__vmalloc_node_range+0xb1c/0x14c0 mm/vmalloc.c:3316
alloc_thread_stack_node kernel/fork.c:309 [inline]
dup_task_struct kernel/fork.c:1112 [inline]
copy_process+0x13bb/0x75c0 kernel/fork.c:2329
kernel_clone+0xeb/0x890 kernel/fork.c:2911
__do_sys_clone+0xba/0x100 kernel/fork.c:3054
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:1161 [inline]
free_unref_page_prepare+0x62e/0xcb0 mm/page_alloc.c:2348
free_unref_page_list+0xe3/0xa70 mm/page_alloc.c:2489
release_pages+0xcd8/0x1380 mm/swap.c:1042
tlb_batch_pages_flush+0xa8/0x1a0 mm/mmu_gather.c:97
tlb_flush_mmu_free mm/mmu_gather.c:292 [inline]
tlb_flush_mmu mm/mmu_gather.c:299 [inline]
tlb_finish_mmu+0x14b/0x7e0 mm/mmu_gather.c:391
exit_mmap+0x2cd/0x960 mm/mmap.c:3208
__mmput+0x128/0x4c0 kernel/fork.c:1347
mmput+0x60/0x70 kernel/fork.c:1369
exit_mm kernel/exit.c:567 [inline]
do_exit+0x9a7/0x29a0 kernel/exit.c:861
do_group_exit+0xd4/0x2a0 kernel/exit.c:1024
get_signal+0x249b/0x25f0 kernel/signal.c:2877
arch_do_signal_or_restart+0x79/0x5c0 arch/x86/kernel/signal.c:308
exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
exit_to_user_mode_prepare+0x11f/0x240 kernel/entry/common.c:204
__syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]
syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:297
do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x63/0xcd

Memory state around the buggy address:
ffffc90012807d00: 00 00 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00
ffffc90012807d80: 00 f1 f1 f1 f1 00 f3 f3 f3 00 00 00 00 00 00 00
>ffffc90012807e00: 00 00 00 00 00 00 f1 f1 f1 f1 f1 f1 04 f2 00 f2
^
ffffc90012807e80: f2 f2 00 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
ffffc90012807f00: 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 syzk...@googlegroups.com.

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

If the bug is already fixed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to change bug's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the bug is a duplicate of another bug, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[syzbot]

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