Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <00000000000053da9405bd7d2644@google.com> <000000000000a17fb305be0b3f38@google.com>
 <20210322071801.GE3440@lst.de>
In-Reply-To: <20210322071801.GE3440@lst.de>
From:   Dmitry Vyukov <dvyukov@google.com>
Date:   Mon, 22 Mar 2021 08:49:45 +0100
Message-ID: <CACT4Y+bDdmUH4eJV0P7OwT_z1pSi3CWs9fFrtiO89obtK6mpcw@mail.gmail.com>
Subject: Re: [syzbot] KASAN: use-after-free Read in disk_part_iter_next (2)
To:     Christoph Hellwig <hch@lst.de>
Cc:     syzbot <syzbot+8fede7e30c7cee0de139@syzkaller.appspotmail.com>,
        Jens Axboe <axboe@kernel.dk>,
        linux-block <linux-block@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
        Tejun Heo <tj@kernel.org>
Content-Type: multipart/mixed; boundary="000000000000e24a1905be1b4ff7"
Precedence: bulk

--000000000000e24a1905be1b4ff7
Content-Type: text/plain; charset="UTF-8"

On Mon, Mar 22, 2021 at 8:18 AM Christoph Hellwig <hch@lst.de> wrote:
>
> I've been running the reproducer on a KASAN enable VM for about
> 15 minutes now, but haven't been able to reproduce it.
>
> Is there a way to inject this proposed fix into the syzbot queue?

Hi Christoph,

Yes, since this bug has a reproducer, syzbot can test patches. See:

http://bit.do/syzbot#testing-patches

It would be, for example:

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master


> diff --git a/block/partitions/core.c b/block/partitions/core.c
> index 1a7558917c47d6..f5d5872b89d57e 100644
> --- a/block/partitions/core.c
> +++ b/block/partitions/core.c
> @@ -288,15 +288,12 @@ struct device_type part_type = {
>  void delete_partition(struct block_device *part)
>  {
>         xa_erase(&part->bd_disk->part_tbl, part->bd_partno);
> -       kobject_put(part->bd_holder_dir);
> -       device_del(&part->bd_device);
> -
> -       /*
> -        * Remove the block device from the inode hash, so that it cannot be
> -        * looked up any more even when openers still hold references.
> -        */
>         remove_inode_hash(part->bd_inode);
>
> +       synchronize_rcu();
> +
> +       kobject_put(part->bd_holder_dir);
> +       device_del(&part->bd_device);
>         put_device(&part->bd_device);
>  }

--000000000000e24a1905be1b4ff7
Content-Type: application/octet-stream; name=patch
Content-Disposition: attachment; filename=patch
Content-Transfer-Encoding: base64
Content-ID: <f_kmkaeeyy0>
X-Attachment-Id: f_kmkaeeyy0

ZGlmZiAtLWdpdCBhL2Jsb2NrL3BhcnRpdGlvbnMvY29yZS5jIGIvYmxvY2svcGFydGl0aW9ucy9j
b3JlLmMKaW5kZXggMWE3NTU4OTE3YzQ3ZDYuLmY1ZDU4NzJiODlkNTdlIDEwMDY0NAotLS0gYS9i
bG9jay9wYXJ0aXRpb25zL2NvcmUuYworKysgYi9ibG9jay9wYXJ0aXRpb25zL2NvcmUuYwpAQCAt
Mjg4LDE1ICsyODgsMTIgQEAgc3RydWN0IGRldmljZV90eXBlIHBhcnRfdHlwZSA9IHsKIHZvaWQg
ZGVsZXRlX3BhcnRpdGlvbihzdHJ1Y3QgYmxvY2tfZGV2aWNlICpwYXJ0KQogewogCXhhX2VyYXNl
KCZwYXJ0LT5iZF9kaXNrLT5wYXJ0X3RibCwgcGFydC0+YmRfcGFydG5vKTsKLQlrb2JqZWN0X3B1
dChwYXJ0LT5iZF9ob2xkZXJfZGlyKTsKLQlkZXZpY2VfZGVsKCZwYXJ0LT5iZF9kZXZpY2UpOwot
Ci0JLyoKLQkgKiBSZW1vdmUgdGhlIGJsb2NrIGRldmljZSBmcm9tIHRoZSBpbm9kZSBoYXNoLCBz
byB0aGF0IGl0IGNhbm5vdCBiZQotCSAqIGxvb2tlZCB1cCBhbnkgbW9yZSBldmVuIHdoZW4gb3Bl
bmVycyBzdGlsbCBob2xkIHJlZmVyZW5jZXMuCi0JICovCiAJcmVtb3ZlX2lub2RlX2hhc2gocGFy
dC0+YmRfaW5vZGUpOwogCisJc3luY2hyb25pemVfcmN1KCk7CisKKwlrb2JqZWN0X3B1dChwYXJ0
LT5iZF9ob2xkZXJfZGlyKTsKKwlkZXZpY2VfZGVsKCZwYXJ0LT5iZF9kZXZpY2UpOwogCXB1dF9k
ZXZpY2UoJnBhcnQtPmJkX2RldmljZSk7CiB9Cg==
--000000000000e24a1905be1b4ff7--