Re: [PATCH v3 05/17] scsi-multipath: clone each bio

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Destroying the bio pool before draining inflight IOs during teardown leads to memory corruption.
- [High] Manual cleanup on the dev_set_name() error path after put_device() causes deterministic double-free and use-after-free vulnerabilities.
--

commit 31da3ef05c72ae055a7ebbed278c14967c624ea3
Author: John Garry <john.g.garry@oracle.com>

scsi-multipath: clone each bio

For failover handling, we will take the approach to resubmit each
bio. Unlike NVMe, for SCSI there is no guarantee that any bio submitted
is either all or none completed. As such, for failover handling clone
and submit each bio.

> diff --git a/drivers/scsi/scsi_multipath.c b/drivers/scsi/scsi_multipath.c
> index 6159803d4cbb8..ca4ab720c19af 100644
> --- a/drivers/scsi/scsi_multipath.c
> +++ b/drivers/scsi/scsi_multipath.c
> @@ -96,6 +96,7 @@ static void scsi_mpath_head_release(struct device *dev)
>  		container_of(dev, struct scsi_mpath_head, dev);
>  	struct mpath_head *mpath_head = &scsi_mpath_head->mpath_head;
>  
> +	bioset_exit(&scsi_mpath_head->bio_pool);

[Severity: High]
Does destroying the bio pool here before draining inflight IOs lead to memory
corruption?

If a device is removed, the final reference to the scsi_mpath_head might be
dropped before the underlying request queue is frozen. Because the queue is
not yet drained, inflight cloned bios can still complete after the pool is
destroyed. When they do, scsi_mpath_clone_end_io() calls bio_put(), which
will attempt to return the clone to this destroyed bio_pool, causing a
use-after-free.

>  	ida_free(&scsi_multipath_dev_ida, scsi_mpath_head->index);
>  	mpath_head_uninit(mpath_head);

[ ... ]

> @@ -270,6 +300,8 @@ static struct scsi_mpath_head *scsi_mpath_alloc_head(void)
>  	ida_free(&scsi_multipath_dev_ida, scsi_mpath_head->index);
>  out_put_head:
>  	mpath_put_head(&scsi_mpath_head->mpath_head);
> +out_bioset_exit:
> +	bioset_exit(&scsi_mpath_head->bio_pool);
>  out_free:
>  	kfree(scsi_mpath_head);

[Severity: High]
Can this error cleanup path cause a double-free vulnerability?

If dev_set_name() fails earlier in scsi_mpath_alloc_head(), the code will
call put_device() which drops the kobject reference count and synchronously
invokes scsi_mpath_head_release().

scsi_mpath_head_release() completely tears down and frees the scsi_mpath_head
structure, but the error path then continues through these manual cleanup
steps, executing bioset_exit() and kfree() on the already freed pointer.

>  	return NULL;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703103402.3725011-1-john.g.garry@oracle.com?part=5