Re: [PATCH v4 09/28] libmultipath: Add support for block device IOCTL

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Bypass of partition-based security restrictions for block ioctls by passing the underlying whole-disk block device (part0) to the lower driver's ioctl.
- [High] Holding the SRCU read lock around the underlying block device IOCTL causes an ABBA deadlock if the IOCTL triggers or blocks on path removal.
--

--- Patch [9]: [PATCH v4 09/28] libmultipath: Add support for block device IOCTL ---
commit 8ca4b41fee0b6082cd169ad8577365e7f205461d
Author: John Garry <john.garry@linux.dev>
Subject: libmultipath: Add support for block device IOCTL

This commit adds mpath_bdev_ioctl() as a multipath block device ioctl
handler. It delegates the ioctls to the underlying path's block device
operations.

> diff --git a/lib/multipath.c b/lib/multipath.c
> index 0232f51f64742..fc8ba8fc501f1 100644
> --- a/lib/multipath.c
> +++ b/lib/multipath.c

[ ... ]

> @@ -478,11 +478,44 @@ static void mpath_bdev_release(struct gendisk *disk)
>  	mpath_put_head(mpath_head);
>  }
>  
> +static int mpath_bdev_ioctl(struct block_device *bdev, blk_mode_t mode,
> +		    unsigned int cmd, unsigned long arg)
> +{
> +	struct gendisk *disk = bdev->bd_disk;
> +	struct mpath_head *mpath_head = mpath_gendisk_to_head(disk);
> +	struct mpath_device *mpath_device;
> +	int srcu_idx, err;
> +
> +	srcu_idx = srcu_read_lock(&mpath_head->srcu);
> +	mpath_device = mpath_find_path(mpath_head);
> +	if (!mpath_device) {
> +		err = -EWOULDBLOCK;
> +		goto out_unlock;
> +	}
> +
> +	if (!mpath_device->disk->fops->ioctl) {
> +		err = -EOPNOTSUPP;
> +		goto out_unlock;
> +	}
> +
> +	err = mpath_device->disk->fops->ioctl(
> +			mpath_device->disk->part0, mode, cmd, arg);

[Severity: Critical]
Does passing part0 bypass partition-based security restrictions in the
underlying driver?

When an unprivileged user issues an ioctl on a multipath partition, this
code delegates it but passes the whole-disk block device (part0) instead of
the partition's block device.

Underlying drivers, such as NVMe via nvme_ioctl(), rely on
bdev_is_partition() to detect partition-level access and deny unprivileged
passthrough commands. Since part0 is passed, bdev_is_partition() evaluates
to false, tricking the lower driver into skipping containment checks.

Could this allow unprivileged users with access to a multipath partition to
execute passthrough commands on the entire underlying physical device?

[Severity: High]
Can holding the SRCU read lock across the underlying ioctl cause a deadlock?

If the underlying ioctl initiates a path removal, such as a passthrough
command that deletes an NVMe namespace or resets a controller, the teardown
code path will synchronously wait for SRCU readers to exit via
synchronize_srcu().

Since the ioctl thread still holds the SRCU read lock while waiting for the
command or removal to complete, synchronize_srcu() will block forever.

> +out_unlock:
> +	srcu_read_unlock(&mpath_head->srcu, srcu_idx);
> +	return err;
> +}

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