Re: [PATCH v5 05/27] libmultipath: Add support for mpath_device management

On 27/07/2026 16:03, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] `mpath_delete_device()` calls `mpath_synchronize()` without first removing the device from `current_path`, risking a use-after-free if callers rely on it for full synchronization.
> --
> 
> --- Patch [5]: [PATCH v5 05/27] libmultipath: Add support for mpath_device management ---
> commit 036ecbe8e851ac2a476516f8e8a72ff07e94750c
> Author: John Garry <[email protected]>
> 
> libmultipath: Add support for mpath_device management
> 
> This commit adds support to add or remove an mpath_device as a path.
> It introduces equivalents to NVMe mpath functions like clearing, adding,
> and removing sysfs links, as well as revalidating paths.
> 
>> diff --git a/lib/multipath.c b/lib/multipath.c
>> index db5f83ebe5d7f..f70049b6cede9 100644
>> --- a/lib/multipath.c
>> +++ b/lib/multipath.c
> 
> [ ... ]
> 
>> +bool mpath_delete_device(struct mpath_device *mpath_device)
>> +{
>> +	bool empty;
>> +
>> +	mutex_lock(&mpath_device->mpath_head->lock);
>> +	list_del_rcu(&mpath_device->siblings);
>> +	empty = list_empty(&mpath_device->mpath_head->dev_list);
>> +	mutex_unlock(&mpath_device->mpath_head->lock);
>> +
>> +	mpath_synchronize(mpath_device->mpath_head);
> 
> [Severity: Medium]
> Does this code leave the device accessible to new RCU readers via the
> current_path array?
> 

it is removed in sd_mpath_remove() -> mpath_clear_current_path()

> By calling mpath_synchronize() here without first removing the device from
> current_path (for example, by calling mpath_clear_current_path() before
> synchronization), new RCU readers could still find and access the device.
> If callers assume mpath_delete_device() provides full synchronization and
> subsequently free the device, could this lead to a use-after-free?
> 
>> +
>> +	return empty;
>> +}
>