Re: [RFC PATCH] blk-mq: Clean up references when freeing rqs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/12/2020 11:36, John Garry wrote:

OK, but another thing to say is that I need to find a somewhat reliable reproducer for the potential problem you mention. So far this patch solves the issue I see (in that kasan stops warning). Let me analyze this a bit further.


Hi Ming,

I am just looking at this again, and have some doubt on your concern [0].

From checking blk_mq_queue_tag_busy_iter() specifically, don't we actually guard against this with the q->q_usage_counter mechanism? That is, an agent needs to grab a q counter ref when attempting the iter. This will fail when the queue IO sched is being changed, as we freeze the queue during this time, which is when the requests are freed, so no agent can hold a reference to a freed request then. And same goes for blk_mq_update_nr_requests(), where we freeze the queue.

But I didn't see such a guard for blk_mq_tagset_busy_iter().


So I was able to trigger a use-after-free BUG in blk_mq_tagset_busy_iter() even with my change, but I needed to add a delay, as follows:

--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -278,6 +278,7 @@ static bool bt_tags_iter(struct sbitmap *bitmap, unsigned int bitnr, void *data)
                rq = tags->rqs[bitnr];
        if (!rq)
                return true;
+       msleep(50);
        if ((iter_data->flags & BT_TAG_ITER_STARTED) &&
            !blk_mq_request_started(rq))
                return true;


And here's the splat:

[ 319.771745] BUG: KASAN: use-after-free in bt_tags_iter+0xe0/0x128 [ 319.777832] Read of size 4 at addr ffff0010b6bd27cc by task more/1866
[  319.784262]
[ 319.785753] CPU: 61 PID: 1866 Comm: more Tainted: G W 5.10.0-rc4-18118-gaa7b9c30d8ff #1070 [ 319.795312] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018
[  319.804437] Call trace:
[  319.806892]  dump_backtrace+0x0/0x2d0
[  319.810552]  show_stack+0x18/0x68
[  319.813865]  dump_stack+0x100/0x16c
[  319.817348]  print_address_description.constprop.12+0x6c/0x4e8
[  319.823176]  kasan_report+0x130/0x200
[  319.826831]  __asan_load4+0x9c/0xd8
[  319.830315]  bt_tags_iter+0xe0/0x128
[  319.833884]  __blk_mq_all_tag_iter+0x320/0x3a8
[  319.838320]  blk_mq_tagset_busy_iter+0x8c/0xd8
[  319.842760]  scsi_host_busy+0x88/0xb8
[  319.846418]  show_host_busy+0x1c/0x48
[  319.850079]  dev_attr_show+0x44/0x90
[  319.853655]  sysfs_kf_seq_show+0x128/0x1c8
[  319.857744]  kernfs_seq_show+0xa0/0xb8
[  319.861489]  seq_read_iter+0x1ec/0x6a0
[  319.865230]  seq_read+0x1d0/0x250
[  319.868539]  kernfs_fop_read+0x70/0x330
[  319.872369]  vfs_read+0xe4/0x250
[  319.875590]  ksys_read+0xc8/0x178
[  319.878898]  __arm64_sys_read+0x44/0x58
[  319.882730]  el0_svc_common.constprop.2+0xc4/0x1e8
[  319.887515]  do_el0_svc+0x90/0xa0
[  319.890824]  el0_sync_handler+0x128/0x178
[  319.894825]  el0_sync+0x158/0x180
[  319.898131]
[  319.899614] The buggy address belongs to the page:
[ 319.904403] page:000000004e9e6864 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10b6bd2
[  319.913876] flags: 0xbfffc0000000000()
[ 319.917626] raw: 0bfffc0000000000 0000000000000000 fffffe0000000000 0000000000000000 [ 319.925363] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[  319.933096] page dumped because: kasan: bad access detected
[  319.938658]
[  319.940141] Memory state around the buggy address:
[ 319.944925] ffff0010b6bd2680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 319.952139] ffff0010b6bd2700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 319.959354] >ffff0010b6bd2780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  319.966566] ^
[ 319.972131] ffff0010b6bd2800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 319.979344] ffff0010b6bd2880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 319.986557] ==================================================================
[  319.993770] Disabling lock debugging due to kernel taint

So to trigger this, I start fio on a disk, and then have one script which constantly enables and disables an IO scheduler for that disk, and another which constantly reads /sys/class/scsi_host/host0/host_busy.

I need the delay to make triggering the issue quick, as the window is so small between the tag bit being cleared at the point the queue is being frozen, and clearing the reference in the tagset.

Anyway, solving this doesn't look trivial...

Thanks,
john



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux