Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Subject: Re: [PATCH -next] ubi: block: Fix use-after-free in ubiblock_cleanup
To:     ZhaoLong Wang <wangzhaolong1@huawei.com>, <richard@nod.at>,
        <miquel.raynal@bootlin.com>, <vigneshr@ti.com>,
        <chaitanya.kulkarni@wdc.com>, <axboe@kernel.dk>
CC:     <linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
        <yi.zhang@huawei.com>
References: <20230921020142.2562687-1-wangzhaolong1@huawei.com>
From:   Zhihao Cheng <chengzhihao1@huawei.com>
Message-ID: <dce695b6-a4ca-82d6-a4c4-02342b4d57f0@huawei.com>
Date:   Thu, 21 Sep 2023 10:39:01 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <20230921020142.2562687-1-wangzhaolong1@huawei.com>
Content-Type: text/plain; charset="gbk"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

?? 2023/9/21 10:01, ZhaoLong Wang д??:
> The following BUG is reported when a ubiblock is removed:
> 
>   ==================================================================
>   BUG: KASAN: slab-use-after-free in ubiblock_cleanup+0x88/0xa0 [ubi]
>   Read of size 4 at addr ffff88810c8f3804 by task ubiblock/1716
> 
>   CPU: 5 PID: 1716 Comm: ubiblock Not tainted 6.6.0-rc2+ #135
>   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
>   Call Trace:
>    <TASK>
>    dump_stack_lvl+0x37/0x50
>    print_report+0xd0/0x620
>    kasan_report+0xb6/0xf0
>    ubiblock_cleanup+0x88/0xa0 [ubi]
>    ubiblock_remove+0x121/0x190 [ubi]
>    vol_cdev_ioctl+0x355/0x630 [ubi]
>    __x64_sys_ioctl+0xc7/0x100
>    do_syscall_64+0x3f/0x90
>    entry_SYSCALL_64_after_hwframe+0x6e/0xd8
>   RIP: 0033:0x7f08d7445577
>   Code: b3 66 90 48 8b 05 11 89 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e1 8
>   RSP: 002b:00007ffde05a3018 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
>   RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007f08d7445577
>   RDX: 0000000000000000 RSI: 0000000000004f08 RDI: 0000000000000003
>   RBP: 0000000000816010 R08: 00000000008163a7 R09: 0000000000000000
>   R10: 0000000000000003 R11: 0000000000000206 R12: 0000000000000003
>   R13: 00007ffde05a3130 R14: 0000000000000000 R15: 0000000000000000
>    </TASK>
> 
>   Allocated by task 1715:
>    kasan_save_stack+0x22/0x50
>    kasan_set_track+0x25/0x30
>    __kasan_kmalloc+0x7f/0x90
>    __alloc_disk_node+0x40/0x2b0
>    __blk_mq_alloc_disk+0x3e/0xb0
>    ubiblock_create+0x2ba/0x620 [ubi]
>    vol_cdev_ioctl+0x581/0x630 [ubi]
>    __x64_sys_ioctl+0xc7/0x100
>    do_syscall_64+0x3f/0x90
>    entry_SYSCALL_64_after_hwframe+0x6e/0xd8
> 
>   Freed by task 0:
>    kasan_save_stack+0x22/0x50
>    kasan_set_track+0x25/0x30
>    kasan_save_free_info+0x2b/0x50
>    __kasan_slab_free+0x10e/0x190
>    __kmem_cache_free+0x96/0x220
>    bdev_free_inode+0xa4/0xf0
>    rcu_core+0x496/0xec0
>    __do_softirq+0xeb/0x384
> 
>   The buggy address belongs to the object at ffff88810c8f3800
>    which belongs to the cache kmalloc-1k of size 1024
>   The buggy address is located 4 bytes inside of
>    freed 1024-byte region [ffff88810c8f3800, ffff88810c8f3c00)
> 
>   The buggy address belongs to the physical page:
>   page:00000000d03de848 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10c8f0
>   head:00000000d03de848 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
>   flags: 0x200000000000840(slab|head|node=0|zone=2)
>   page_type: 0xffffffff()
>   raw: 0200000000000840 ffff888100042dc0 ffffea0004244400 dead000000000002
>   raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
>   page dumped because: kasan: bad access detected
> 
>   Memory state around the buggy address:
>    ffff88810c8f3700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>    ffff88810c8f3780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>   >ffff88810c8f3800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>                      ^
>    ffff88810c8f3880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>    ffff88810c8f3900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>   ==================================================================
> 
> Fix it by using a local variable to record the gendisk ID.
> 
> Fixes: 77567b25ab9f ("ubi: use blk_mq_alloc_disk and blk_cleanup_disk")
> Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
> ---
>   drivers/mtd/ubi/block.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 

Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>

> diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c
> index 437c5b83ffe5..309a42aeaa4c 100644
> --- a/drivers/mtd/ubi/block.c
> +++ b/drivers/mtd/ubi/block.c
> @@ -447,13 +447,15 @@ int ubiblock_create(struct ubi_volume_info *vi)
>   
>   static void ubiblock_cleanup(struct ubiblock *dev)
>   {
> +	int id = dev->gd->first_minor;
> +
>   	/* Stop new requests to arrive */
>   	del_gendisk(dev->gd);
>   	/* Finally destroy the blk queue */
>   	dev_info(disk_to_dev(dev->gd), "released");
>   	put_disk(dev->gd);
>   	blk_mq_free_tag_set(&dev->tag_set);
> -	idr_remove(&ubiblock_minor_idr, dev->gd->first_minor);
> +	idr_remove(&ubiblock_minor_idr, id);
>   }
>   
>   int ubiblock_remove(struct ubi_volume_info *vi)
>