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

[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+d2dd123304b4ae59f1bd@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 syzkaller@googlegroups.com.

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

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

[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+d2dd123304b4ae59f1bd@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
==================================================================

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

[syzbot]

syzbot has bisected this issue to:

commit 4cd4aed63125ccd4efc35162627827491c2a7be7
Author: Christoph Hellwig <hch@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+d2dd123304b4ae59f1bd@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

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

[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 <hch@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;
	}
---

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

[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 <hch@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?

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

[Qu Wenruo]

On 2022/6/14 15:17, 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 <hch@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?

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

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

[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?

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

[Qu Wenruo]

On 2022/6/15 21:21, Christoph Hellwig wrote:
> 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?

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

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

[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 !

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

[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 <hch@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.