[syzbot] KASAN: use-after-free Read in copy_page_from_iter_atomic (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 73d0e32571a0 Add linux-next specific files for 20220607
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1433bacff00000
kernel config: https://syzkaller.appspot.com/x/.config?x=448ee2b64e828049
dashboard link: https://syzkaller.appspot.com/bug?extid=d2dd123304b4ae59f1bd
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

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

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

BTRFS error (device loop2): bad tree block start, want 22036480 have 0
==================================================================
BUG: KASAN: use-after-free in copy_page_from_iter_atomic+0xef6/0x1b30 lib/iov_iter.c:969
Read of size 4096 at addr ffff888177101000 by task kworker/u4:30/4131

CPU: 0 PID: 4131 Comm: kworker/u4:30 Not tainted 5.19.0-rc1-next-20220607-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: loop2 loop_workfn
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0xeb/0x495 mm/kasan/report.c:313
print_report mm/kasan/report.c:429 [inline]
kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491
check_region_inline mm/kasan/generic.c:183 [inline]
kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189
memcpy+0x20/0x60 mm/kasan/shadow.c:65
copy_page_from_iter_atomic+0xef6/0x1b30 lib/iov_iter.c:969
generic_perform_write+0x2b8/0x560 mm/filemap.c:3734
__generic_file_write_iter+0x2aa/0x4d0 mm/filemap.c:3854
generic_file_write_iter+0xd7/0x220 mm/filemap.c:3886
call_write_iter include/linux/fs.h:2059 [inline]
do_iter_readv_writev+0x3d1/0x640 fs/read_write.c:742
do_iter_write+0x182/0x700 fs/read_write.c:868
vfs_iter_write+0x70/0xa0 fs/read_write.c:909
lo_write_bvec drivers/block/loop.c:249 [inline]
lo_write_simple drivers/block/loop.c:271 [inline]
do_req_filebacked drivers/block/loop.c:495 [inline]
loop_handle_cmd drivers/block/loop.c:1859 [inline]
loop_process_work+0xd83/0x2050 drivers/block/loop.c:1894
process_one_work+0x996/0x1610 kernel/workqueue.c:2289
worker_thread+0x665/0x1080 kernel/workqueue.c:2436
kthread+0x2e9/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
</TASK>

The buggy address belongs to the physical page:
page:ffffea0005dc4040 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x177101
flags: 0x57ff00000000000(node=1|zone=2|lastcpupid=0x7ff)
raw: 057ff00000000000 ffffea0005dc4048 ffffea0005dc4048 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner info is not present (never set?)

Memory state around the buggy address:
ffff888177100f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff888177100f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff888177101000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff888177101080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff888177101100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================


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

syzbot has found a reproducer for the following issue on:

HEAD commit: ff539ac73ea5 Add linux-next specific files for 20220609
git tree: linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=1627d920080000
kernel config: https://syzkaller.appspot.com/x/.config?x=a5002042f00a8bce

dashboard link: https://syzkaller.appspot.com/bug?extid=d2dd123304b4ae59f1bd
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10d6d7cff00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1113b2bff00000

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

BTRFS error (device loop0): bad tree block start, want 30490624 have 0

==================================================================
BUG: KASAN: use-after-free in copy_page_from_iter_atomic+0xef6/0x1b30 lib/iov_iter.c:969

Read of size 4096 at addr ffff888170801000 by task kworker/u4:0/8

CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.19.0-rc1-next-20220609-syzkaller #0

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

Workqueue: loop0 loop_rootcg_workfn

Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0xeb/0x495 mm/kasan/report.c:313
print_report mm/kasan/report.c:429 [inline]
kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491
check_region_inline mm/kasan/generic.c:183 [inline]
kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189
memcpy+0x20/0x60 mm/kasan/shadow.c:65
copy_page_from_iter_atomic+0xef6/0x1b30 lib/iov_iter.c:969

generic_perform_write+0x2b8/0x560 mm/filemap.c:3735
__generic_file_write_iter+0x2aa/0x4d0 mm/filemap.c:3855
generic_file_write_iter+0xd7/0x220 mm/filemap.c:3887
call_write_iter include/linux/fs.h:2057 [inline]

do_iter_readv_writev+0x3d1/0x640 fs/read_write.c:742
do_iter_write+0x182/0x700 fs/read_write.c:868
vfs_iter_write+0x70/0xa0 fs/read_write.c:909
lo_write_bvec drivers/block/loop.c:249 [inline]
lo_write_simple drivers/block/loop.c:271 [inline]
do_req_filebacked drivers/block/loop.c:495 [inline]
loop_handle_cmd drivers/block/loop.c:1859 [inline]
loop_process_work+0xd83/0x2050 drivers/block/loop.c:1894
process_one_work+0x996/0x1610 kernel/workqueue.c:2289
worker_thread+0x665/0x1080 kernel/workqueue.c:2436
kthread+0x2e9/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
</TASK>

The buggy address belongs to the physical page:

page:ffffea0005c20040 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x170801
flags: 0x57ff00000000000(node=1|zone=2|lastcpupid=0x7ff)
raw: 057ff00000000000 ffffea0005c20048 ffffea0005c20048 0000000000000000

raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner info is not present (never set?)

Memory state around the buggy address:

ffff888170800f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff888170800f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff888170801000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff888170801080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff888170801100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================

[syzbot]

syzbot has bisected this issue to:

commit 4cd4aed63125ccd4efc35162627827491c2a7be7
Author: Christoph Hellwig <h...@lst.de>
Date: Fri May 27 08:43:20 2022 +0000

btrfs: fold repair_io_failure into btrfs_repair_eb_io_failure

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1332525ff00000
start commit: ff539ac73ea5 Add linux-next specific files for 20220609
git tree: linux-next
final oops: https://syzkaller.appspot.com/x/report.txt?x=10b2525ff00000
console output: https://syzkaller.appspot.com/x/log.txt?x=1732525ff00000

kernel config: https://syzkaller.appspot.com/x/.config?x=a5002042f00a8bce
dashboard link: https://syzkaller.appspot.com/bug?extid=d2dd123304b4ae59f1bd

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10d6d7cff00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1113b2bff00000

Reported-by: syzbot+d2dd12...@syzkaller.appspotmail.com
Fixes: 4cd4aed63125 ("btrfs: fold repair_io_failure into btrfs_repair_eb_io_failure")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

[David Sterba]

On Fri, Jun 10, 2022 at 12:10:19AM -0700, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 4cd4aed63125ccd4efc35162627827491c2a7be7
> Author: Christoph Hellwig <h...@lst.de>
> Date: Fri May 27 08:43:20 2022 +0000
>
> btrfs: fold repair_io_failure into btrfs_repair_eb_io_failure

Josef also reported a crash and found a bug in the patch, now added as
fixup that'll be in for-next:

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 89a319e65197..5eac9ffb7499 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2260,7 +2260,7 @@ int btrfs_repair_eb_io_failure(const struct extent_buffer *eb, int mirror_num)
__bio_add_page(&bio, p, PAGE_SIZE, start - page_offset(p));
ret = btrfs_map_repair_bio(fs_info, &bio, mirror_num);
bio_uninit(&bio);
-
+ start += PAGE_SIZE;
if (ret)
return ret;
}
---

[Christoph Hellwig]

On Mon, Jun 13, 2022 at 09:39:12PM +0200, David Sterba wrote:
> On Fri, Jun 10, 2022 at 12:10:19AM -0700, syzbot wrote:
> > syzbot has bisected this issue to:
> >
> > commit 4cd4aed63125ccd4efc35162627827491c2a7be7
> > Author: Christoph Hellwig <h...@lst.de>
> > Date: Fri May 27 08:43:20 2022 +0000
> >
> > btrfs: fold repair_io_failure into btrfs_repair_eb_io_failure
>
> Josef also reported a crash and found a bug in the patch, now added as
> fixup that'll be in for-next:

The patch looks correct to me. Two things to note here:

- I hadn't realized you had queued up the series. I've actually
started to merge some of my bio work with the bio split at
submission time work from Qu and after a few iterations I think
I would do the repair code a bit differently based on that.
Can you just drop the series for now?
- I find it interesting that syzbot hits btrfs metadata repair.
xfstests seems to have no coverage and I could not come up with
a good idea how to properly test it. Does anyone have a good
idea on how to intentially corrupt metadata in a deterministic
way?

[Qu Wenruo]

The same way as data?

map-logical to find the location of a mirror, write 4 bytes of zero into
the location, then call it a day.

Although for metadata, you may want to choose a metadata that would
definitely get read.
Thus tree root is a good candidate.

Thanks,
Qu

[Christoph Hellwig]

On Tue, Jun 14, 2022 at 04:50:22PM +0800, Qu Wenruo wrote:
> The same way as data?
>
> map-logical to find the location of a mirror, write 4 bytes of zero into
> the location, then call it a day.
>
> Although for metadata, you may want to choose a metadata that would
> definitely get read.
> Thus tree root is a good candidate.

And how do I find out the logic address of the tree root?

[Qu Wenruo]

For tree root, "btrfs ins dump-super <dev> | grep '^root\s'.

For other tree blocks, "btrfs ins dump-tree <dev>" then with other other
keywords to grab.

Thanks,
Qu

[Christoph Hellwig]

On Thu, Jun 16, 2022 at 05:27:04AM +0800, Qu Wenruo wrote:
>> And how do I find out the logic address of the tree root?
>
> For tree root, "btrfs ins dump-super <dev> | grep '^root\s'.
>
> For other tree blocks, "btrfs ins dump-tree <dev>" then with other other
> keywords to grab.

Thanks a lot !

[David Sterba]

On Tue, Jun 14, 2022 at 09:17:57AM +0200, Christoph Hellwig wrote:
> On Mon, Jun 13, 2022 at 09:39:12PM +0200, David Sterba wrote:
> > On Fri, Jun 10, 2022 at 12:10:19AM -0700, syzbot wrote:
> > > syzbot has bisected this issue to:
> > >
> > > commit 4cd4aed63125ccd4efc35162627827491c2a7be7
> > > Author: Christoph Hellwig <h...@lst.de>
> > > Date: Fri May 27 08:43:20 2022 +0000
> > >
> > > btrfs: fold repair_io_failure into btrfs_repair_eb_io_failure
> >
> > Josef also reported a crash and found a bug in the patch, now added as
> > fixup that'll be in for-next:
>
> The patch looks correct to me. Two things to note here:
>
> - I hadn't realized you had queued up the series.

I did a review and as it looked ok I added it to the for-next for
testing coverage, but I don't think I've sent any notice about that.

> I've actually
> started to merge some of my bio work with the bio split at
> submission time work from Qu and after a few iterations I think
> I would do the repair code a bit differently based on that.
> Can you just drop the series for now?

Yeah, we consistently hit 2 crashes, one of them has a fix but the other
not, so I removed the topic branch from for-next. I'll wait for the
reworked version you mention.

[Aleksandr Nogikh]

#syz set subsystems: btrfs

> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bug...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/0000000000003ce9d105e0db53c8%40google.com.

[syzbot]

> #syz set subsystems: btrfs

Thank you!

I've successfully updated the bug's subsystems.

[syzbot]

Auto-closing this bug as obsolete.
No recent activity, existing reproducers are no longer triggering the issue.