Re: [PATCH v3 1/7] block: fail reads to offline zones early

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] block: slab-out-of-bounds read in disk_zone_get_state() due to race with capacity expansion
--

commit 891363eb78b3eced11718bdb36c5d62832506870
Author: Damien Le Moal <dlemoal@kernel.org>

block: fail reads to offline zones early

Any BIO targeting an offline zone of a zoned block device will fail,
including read commands. This commit fails these read operations early if we
ever see one.

> diff --git a/block/blk-core.c b/block/blk-core.c
> index 8836c7028568b..5c6be90e5d7f6 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -867,6 +867,9 @@ void submit_bio_noacct(struct bio *bio)
>  
>  	switch (bio_op(bio)) {
>  	case REQ_OP_READ:
> +		if (bdev_is_zoned(bdev) &&
> +		    bdev_zone_is_offline(bdev, bio->bi_iter.bi_sector))

[Severity: High]
Could this introduce a data race leading to a slab-out-of-bounds read?

Looking at the fast path in submit_bio_noacct(), this evaluates
bdev_zone_is_offline() locklessly before blk_queue_enter() is called to
freeze the queue. 

Concurrently, disk_revalidate_zone_resources() can expand the zone capacity
and update disk->nr_zones before replacing the RCU-protected zones_state 
array:

block/blk-zoned.c:disk_revalidate_zone_resources() {
    ...
    disk->nr_zones = args->nr_zones;
    ...
    disk_set_zones_state_array(disk, args->zones_state);
}

Because disk->nr_zones is updated independently of the disk->zones_state
array replacement, a reader in disk_zone_get_state() might fetch the new,
larger nr_zones value but still dereference the old, smaller zones_state
array pointer.

If a read bio targets a sector in the newly expanded region, the bounds
check in disk_zone_get_state() would pass incorrectly:

block/blk-zoned.c:disk_zone_get_state() {
    ...
    zones_state = rcu_dereference(disk->zones_state);
    if (likely(zones_state && zno < disk->nr_zones))
        zs = zones_state[zno];
    ...
}

This would lead to an out-of-bounds read on the old array allocation. Should
we ensure the queue is entered or otherwise protect against concurrent zone
revalidation before checking the offline status?

> +			goto end_io;
>  		break;
>  	case REQ_OP_WRITE:

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007082344.1049179-1-dlemoal@kernel.org?part=1