Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <2cc67037-cf90-cca2-1655-46b92b43eba8@gmx.com>
Date:   Tue, 14 Jun 2022 16:50:22 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: [syzbot] KASAN: use-after-free Read in copy_page_from_iter_atomic
 (2)
Content-Language: en-US
To:     Christoph Hellwig <hch@lst.de>, dsterba@suse.cz,
        syzbot <syzbot+d2dd123304b4ae59f1bd@syzkaller.appspotmail.com>,
        akpm@linux-foundation.org, clm@fb.com, dsterba@suse.com,
        josef@toxicpanda.com, linux-btrfs@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org, syzkaller-bugs@googlegroups.com,
        willy@infradead.org
References: <0000000000003ce9d105e0db53c8@google.com>
 <00000000000085068105e112a117@google.com>
 <20220613193912.GI20633@twin.jikos.cz> <20220614071757.GA1207@lst.de>
From:   Qu Wenruo <quwenruo.btrfs@gmx.com>
In-Reply-To: <20220614071757.GA1207@lst.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


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