Re: [PATCH 2/5] s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] Uninitialized Memory Usage in `vfio_ap_mdev_hot_plug_cfg` leads to random hardware queue resets.
- [High] Use-After-Free in KVM's `pqap_hook` due to improper error rollback in `vfio_ap_mdev_set_kvm`.
- [High] Unsafe concurrent modification and iteration of `matrix_dev->mdev_list` leading to Data Race / UAF.
--

--- Patch [2]: [PATCH 2/5] s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL ---
commit 9e16afa935b6610f6431f2a073e3d436ec0b7f7d
Author: Anthony Krowiak <akrowiak@linux.ibm.com>

s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL

This commit resolves a potential NULL pointer dereference in the AP bus scan
callbacks by explicitly checking if matrix_mdev->kvm is set before acquiring
its lock. It also adjusts the lock acquisition order in these callbacks.

Cc: stable@vger.kernel.org

> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> index 845c86ba8bc30..e382e5a1cb996 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c

[ ... ]

> @@ -2821,9 +2828,6 @@ static void vfio_ap_mdev_hot_plug_cfg(struct ap_matrix_mdev *matrix_mdev)
>  	DECLARE_BITMAP(apm_filtered, AP_DEVICES);
>  	bool filter_domains, filter_adapters, filter_cdoms, do_hotplug = false;
>  
> -	mutex_lock(&matrix_mdev->kvm->lock);
> -	mutex_lock(&matrix_dev->mdevs_lock);
> -
>  	filter_adapters = bitmap_intersects(matrix_mdev->matrix.apm,
>  					    matrix_mdev->apm_add, AP_DEVICES);
>  	filter_domains = bitmap_intersects(matrix_mdev->matrix.aqm,
> @@ -2841,9 +2845,6 @@ static void vfio_ap_mdev_hot_plug_cfg(struct ap_matrix_mdev *matrix_mdev)
>  		vfio_ap_mdev_update_guest_apcb(matrix_mdev);
>  
>  	reset_queues_for_apids(matrix_mdev, apm_filtered);

[Severity: High]
This is a pre-existing issue, but does this function pass an uninitialized
bitmap to reset_queues_for_apids()?

If the AP configuration only adds control domains, filter_cdoms is true, but
both filter_adapters and filter_domains are false. This skips the call to
vfio_ap_mdev_filter_matrix() which initializes apm_filtered:

    if (filter_adapters || filter_domains)
        do_hotplug = vfio_ap_mdev_filter_matrix(matrix_mdev, apm_filtered);

If this initialization path is bypassed, is it possible for apm_filtered to
retain stack garbage when it is subsequently passed to
reset_queues_for_apids(), potentially causing unintended guest hardware
queues to be reset?

> -
> -	mutex_unlock(&matrix_dev->mdevs_lock);
> -	mutex_unlock(&matrix_mdev->kvm->lock);
>  }
>  
>  void vfio_ap_on_scan_complete(struct ap_config_info *new_config_info,
> @@ -2854,15 +2855,29 @@ void vfio_ap_on_scan_complete(struct ap_config_info *new_config_info,
>  	mutex_lock(&matrix_dev->guests_lock);
>  
>  	list_for_each_entry(matrix_mdev, &matrix_dev->mdev_list, node) {

[Severity: High]
This is a pre-existing issue, but could this list iteration race with
concurrent list modifications?

It appears this list traversal in vfio_ap_on_scan_complete() occurs while
holding only matrix_dev->guests_lock at the list level. However, list
mutations such as the one in vfio_ap_mdev_probe():

vfio_ap_mdev_probe() {
    ...
    mutex_lock(&matrix_dev->mdevs_lock);
    list_add(&matrix_mdev->node, &matrix_dev->mdev_list);
    mutex_unlock(&matrix_dev->mdevs_lock);
    ...
}

are protected only by matrix_dev->mdevs_lock. Since the internal iteration
step happens outside of matrix_dev->mdevs_lock, can this expose the reader to
torn or stale pointers, potentially leading to a use-after-free or infinite
loop if an administrator concurrently creates a new mdev?

> +		/*
> +		 * The mdevs_lock must be held to access fields within matrix_mdev,
> +		 * and kvm->lock must be taken before mdevs_lock to satisfy the lock
> +		 * ordering requirement and prevent a lockdep splat.
> +		 */

[ ... ]

While reviewing this file, I also noticed another potential issue outside the
immediate diff in vfio_ap_mdev_set_kvm():

>       kvm->arch.crypto.pqap_hook = &matrix_mdev->pqap_hook;
>       ...
>       if (m != matrix_mdev && m->kvm == kvm) {
>               release_update_locks_for_kvm(kvm);
>               return -EPERM;
>       }

[Severity: High]
This is a pre-existing issue, but is it possible for KVM's pqap_hook to be
left pointing to freed memory upon an error?

The KVM hook is unconditionally updated to point to the incoming matrix_mdev.
However, if another mdev is already attached to this KVM instance, the
function bails out with -EPERM.

If the rejected mdev is subsequently freed by userspace, would KVM retain a
dangling pointer? Could this cause a use-after-free when a guest later
issues a PQAP instruction and handle_pqap() dereferences the hook?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260808170712.839066-1-akrowiak@linux.ibm.com?part=2