From: syzbot <syzbot+e5c1bab304c63c107418@syzkaller.appspotmail.com>
To: clm@fb.com, dsterba@suse.com, josef@toxicpanda.com,
linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: [syzbot] [btrfs?] KASAN: stack-out-of-bounds Read in btrfs_buffered_write
Date: Sat, 30 Sep 2023 14:07:53 -0700 [thread overview]
Message-ID: <0000000000003aa943060699ef0c@google.com> (raw)
Hello,
syzbot found the following issue on:
HEAD commit: df964ce9ef9f Add linux-next specific files for 20230929
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13c348e6680000
kernel config: https://syzkaller.appspot.com/x/.config?x=880c828d75e38e1b
dashboard link: https://syzkaller.appspot.com/bug?extid=e5c1bab304c63c107418
compiler: gcc (Debian 12.2.0-14) 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: https://storage.googleapis.com/syzbot-assets/fe7244c6057d/disk-df964ce9.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/48cdc7f3b2c0/vmlinux-df964ce9.xz
kernel image: https://storage.googleapis.com/syzbot-assets/ce7c93a66da9/bzImage-df964ce9.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+e5c1bab304c63c107418@syzkaller.appspotmail.com
BTRFS info (device loop5): auto enabling async discard
==================================================================
BUG: KASAN: stack-out-of-bounds in iterate_bvec include/linux/iov_iter.h:116 [inline]
BUG: KASAN: stack-out-of-bounds in __copy_from_iter_mc+0x30a/0x3f0 lib/iov_iter.c:262
Read of size 4 at addr ffffc9000a0ff574 by task syz-executor.5/8451
CPU: 0 PID: 8451 Comm: syz-executor.5 Not tainted 6.6.0-rc3-next-20230929-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/06/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:364 [inline]
print_report+0xc4/0x620 mm/kasan/report.c:475
kasan_report+0xda/0x110 mm/kasan/report.c:588
iterate_bvec include/linux/iov_iter.h:116 [inline]
__copy_from_iter_mc+0x30a/0x3f0 lib/iov_iter.c:262
__copy_from_iter lib/iov_iter.c:271 [inline]
copy_page_from_iter_atomic+0x471/0x11e0 lib/iov_iter.c:504
btrfs_copy_from_user+0xe7/0x310 fs/btrfs/file.c:61
btrfs_buffered_write+0xabe/0x12d0 fs/btrfs/file.c:1337
btrfs_do_write_iter+0xa56/0x1120 fs/btrfs/file.c:1686
__kernel_write_iter+0x261/0x7e0 fs/read_write.c:517
dump_emit_page fs/coredump.c:888 [inline]
dump_user_range+0x299/0x790 fs/coredump.c:915
elf_core_dump+0x2700/0x3900 fs/binfmt_elf.c:2142
do_coredump+0x2c97/0x3fc0 fs/coredump.c:764
get_signal+0x2434/0x2790 kernel/signal.c:2890
arch_do_signal_or_restart+0x90/0x7f0 arch/x86/kernel/signal.c:309
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:285 [inline]
syscall_exit_to_user_mode+0x1d/0x60 kernel/entry/common.c:296
do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:87
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f2fa447cae9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f2fa51250c8 EFLAGS: 00000246 ORIG_RAX: 000000000000011d
RAX: ffffffffffffffe5 RBX: 00007f2fa459bf80 RCX: 00007f2fa447cae9
RDX: 0000000100000000 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 00007f2fa44c847a R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007f2fa459bf80 R15: 00007ffd70b99bd8
</TASK>
The buggy address belongs to stack of task syz-executor.5/8451
and is located at offset 108 in frame:
dump_user_range+0x0/0x790 fs/coredump.c:482
This frame has 3 objects:
[48, 56) 'pos'
[80, 96) 'bvec'
[112, 152) 'iter'
The buggy address belongs to the virtual mapping at
[ffffc9000a0f8000, ffffc9000a101000) created by:
kernel_clone+0xfd/0x920 kernel/fork.c:2902
The buggy address belongs to the physical page:
page:ffffea0001fce280 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7f38a
memcg:ffff8880291b7482
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
page_type: 0xffffffff()
raw: 00fff00000000000 0000000000000000 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff ffff8880291b7482
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 8450, tgid 8450 (syz-executor.5), ts 363006042687, free_ts 362824161389
set_page_owner include/linux/page_owner.h:31 [inline]
post_alloc_hook+0x2cf/0x340 mm/page_alloc.c:1534
prep_new_page mm/page_alloc.c:1541 [inline]
get_page_from_freelist+0x98f/0x32a0 mm/page_alloc.c:3333
__alloc_pages+0x1d0/0x4a0 mm/page_alloc.c:4589
alloc_pages+0x1a9/0x270 mm/mempolicy.c:2304
vm_area_alloc_pages mm/vmalloc.c:3063 [inline]
__vmalloc_area_node mm/vmalloc.c:3139 [inline]
__vmalloc_node_range+0x8f3/0x1bf0 mm/vmalloc.c:3320
alloc_thread_stack_node kernel/fork.c:309 [inline]
dup_task_struct kernel/fork.c:1118 [inline]
copy_process+0x13e3/0x74b0 kernel/fork.c:2327
kernel_clone+0xfd/0x920 kernel/fork.c:2902
__do_sys_clone3+0x1f1/0x260 kernel/fork.c:3203
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:81
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:1134 [inline]
free_unref_page_prepare+0x476/0xa40 mm/page_alloc.c:2383
free_unref_page_list+0xe6/0xb30 mm/page_alloc.c:2564
release_pages+0x32a/0x14e0 mm/swap.c:1042
__folio_batch_release+0x77/0xe0 mm/swap.c:1062
folio_batch_release include/linux/pagevec.h:83 [inline]
mapping_try_invalidate+0x39a/0x480 mm/truncate.c:535
invalidate_bdev+0xb1/0xd0 block/bdev.c:87
btrfs_close_bdev+0x11a/0x170 fs/btrfs/volumes.c:1017
btrfs_close_one_device fs/btrfs/volumes.c:1041 [inline]
close_fs_devices fs/btrfs/volumes.c:1086 [inline]
close_fs_devices+0x200/0x980 fs/btrfs/volumes.c:1073
btrfs_close_devices+0x91/0x610 fs/btrfs/volumes.c:1102
btrfs_free_fs_info+0x4b/0x410 fs/btrfs/disk-io.c:1237
deactivate_locked_super+0xbc/0x1a0 fs/super.c:484
deactivate_super+0xde/0x100 fs/super.c:517
cleanup_mnt+0x222/0x3d0 fs/namespace.c:1256
task_work_run+0x14d/0x240 kernel/task_work.c:180
resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
exit_to_user_mode_prepare+0x215/0x240 kernel/entry/common.c:204
__syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
syscall_exit_to_user_mode+0x1d/0x60 kernel/entry/common.c:296
Memory state around the buggy address:
ffffc9000a0ff400: f1 f1 f1 00 00 00 00 00 00 f3 f3 f3 f3 00 00 00
ffffc9000a0ff480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffc9000a0ff500: 00 f1 f1 f1 f1 f1 f1 00 f2 f2 f2 00 00 f2 f2 00
^
ffffc9000a0ff580: 00 00 00 00 f3 f3 f3 f3 f3 00 00 00 00 00 00 00
ffffc9000a0ff600: 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@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 overwrite 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
reply other threads:[~2023-09-30 21:07 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0000000000003aa943060699ef0c@google.com \
--to=syzbot+e5c1bab304c63c107418@syzkaller.appspotmail.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.