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: <CA+G9fYvv6YsRM2Qf7AGMo3nwqkuAt_D1i+6H_ApHk3kmScyDyg@mail.gmail.com>
In-Reply-To: <CA+G9fYvv6YsRM2Qf7AGMo3nwqkuAt_D1i+6H_ApHk3kmScyDyg@mail.gmail.com>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Thu, 21 Oct 2021 14:20:40 +0200
Message-ID: <CAK8P3a21U0jzMOUWp1rhrNrD3szxxrwo59SBYG89xpYJGXteRA@mail.gmail.com>
Subject: Re: BUG: KASAN: use-after-free in blk_mq_sched_tags_teardown
To:     Naresh Kamboju <naresh.kamboju@linaro.org>
Cc:     linux-block <linux-block@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>,
        linux-scsi <linux-scsi@vger.kernel.org>,
        Kashyap Desai <kashyap.desai@broadcom.com>,
        Hannes Reinecke <hare@suse.de>, Ming Lei <ming.lei@redhat.com>,
        John Garry <john.garry@huawei.com>,
        Arnd Bergmann <arnd@arndb.de>, lkft-triage@lists.linaro.org,
        Anders Roxell <anders.roxell@linaro.org>,
        Miquel Raynal <miquel.raynal@bootlin.com>,
        Richard Weinberger <richard@nod.at>,
        Vignesh R <vigneshr@ti.com>,
        linux-mtd <linux-mtd@lists.infradead.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Oct 21, 2021 at 2:01 PM Naresh Kamboju
<naresh.kamboju@linaro.org> wrote:
>
> Following KASAN BUG noticed on linux next 20211021 while booting qemu-arm64
> with allmodconfig.

> [   77.730367][    T5] Freed by task 1:
> [   77.732009][    T5]  kasan_save_stack+0x30/0x80
> [   77.734083][    T5]  kasan_set_track+0x30/0x80
> [   77.736085][    T5]  kasan_set_free_info+0x34/0x80
> [   77.738261][    T5]  ____kasan_slab_free+0xfc/0x1c0
> [   77.740433][    T5]  __kasan_slab_free+0x3c/0x80
> [   77.742518][    T5]  slab_free_freelist_hook+0x1d4/0x2c0
> [   77.744892][    T5]  kfree+0x160/0x300
> [   77.746618][    T5]  blktrans_dev_release+0x64/0x100
> [   77.748821][    T5]  del_mtd_blktrans_dev+0x1c0/0x240
> [   77.751079][    T5]  mtdblock_remove_dev+0x28/0x80
> [   77.753246][    T5]  blktrans_notify_remove+0xa4/0x140
> [   77.755507][    T5]  del_mtd_device+0x84/0x1c0
> [   77.757541][    T5]  mtd_device_unregister+0x90/0xc0
> [   77.759764][    T5]  physmap_flash_remove+0x58/0x180
> [   77.762012][    T5]  platform_remove+0x48/0xc0
> [   77.764032][    T5]  __device_release_driver+0x1dc/0x340
> [   77.766393][    T5]  driver_detach+0x138/0x200
> [   77.768396][    T5]  bus_remove_driver+0x100/0x180
> [   77.770554][    T5]  driver_unregister+0x64/0xc0
> [   77.772633][    T5]  platform_driver_unregister+0x28/0x80
> [   77.775042][    T5]  physmap_init+0xc4/0xfc
> [   77.776994][    T5]  do_one_initcall+0xb0/0x2c0
> [   77.779028][    T5]  do_initcalls+0x17c/0x244
> [   77.781023][    T5]  kernel_init_freeable+0x2d4/0x378
> [   77.783269][    T5]  kernel_init+0x34/0x180
> [   77.785196][    T5]  ret_from_fork+0x10/0x20
> [   77.787135][    T5]
> ...
> full boot log link,
> https://pastebin.com/xL5MYSD6

I think this is related to an earlier bug that Anders reported a while ago,
see [1]. I had looked at it originally, and found that this probably a
device that gets probed from CONFIG_MTD_PHYSMAP_COMPAT
and then freed again immediately after we find the device does not
exist, starting with commit dcb3e137ce9b ("[MTD] physmap: make
physmap compat explicit").

It's not really the fault of CONFIG_MTD_PHYSMAP_COMPAT
describing a nonexisting device, but instead it's something in the
cleanup path.

        Arnd

[1] https://lore.kernel.org/linux-mtd/CADYN=9Kjw_3cDGAvh9=+nNwdYof1kUPKG-SUOP5FsQhZ+gz62Q@mail.gmail.com/