From: Anthony Krowiak <akrowiak@linux.ibm.com>
To: sashiko-reviews@lists.linux.dev
Cc: kvm@vger.kernel.org, Vasily Gorbik <gor@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.vom>,
linux-s390@vger.kernel.org,
Alexander Gordeev <agordeev@linux.ibm.com>
Subject: Re: [PATCH v4 3/9] s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects
Date: Wed, 12 Aug 2026 14:25:35 -0400 [thread overview]
Message-ID: <cb9ff85c-b7a3-4e0c-9250-60a553819c53@linux.ibm.com> (raw)
In-Reply-To: <20260812172858.2B7241F000E9@smtp.kernel.org>
On 8/12/26 1:28 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
>
> Pre-existing issues:
> - [Critical] The sysfs file 'status' is exposed to userspace before the device's driver data is fully initialized, leading to a potential NULL pointer dereference in status_show().
> - [High] A race condition in vfio_ap_mdev_probe() allows userspace to bypass the 'one mdev per KVM' isolation restriction.
> - [High] Eventfd contexts for `req_trigger` and `cfg_chg_trigger` are leaked when the mediated device is closed or removed.
> --
>
> --- Patch [3]: [PATCH v4 3/9] s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects ---
> commit b763c5c7bf7a38cb1fc2e2da2ff0df92d3ae360c
> Author: Anthony Krowiak <akrowiak@linux.ibm.com>
>
> s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects
>
> This patch fixes list traversal synchronization for ap_matrix_mdev objects
> by adding guests_lock around mdev_list access. It also removes redundant
> zero-initialization of eventfd triggers in the probe function.
>
>> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
>> index c6bee69cc22f6..f2d662e388bdc 100644
>> --- a/drivers/s390/crypto/vfio_ap_ops.c
>> +++ b/drivers/s390/crypto/vfio_ap_ops.c
>> @@ -800,12 +800,17 @@ static int vfio_ap_mdev_probe(struct mdev_device *mdev)
>> ret = vfio_register_emulated_iommu_dev(&matrix_mdev->vdev);
> [Severity: High]
> This isn't a bug introduced by this patch, but does exposing the VFIO
> device to userspace here create a race condition?
>
> vfio_register_emulated_iommu_dev() makes the device visible to userspace
> before it is added to matrix_dev->mdev_list under guests_lock. Could
> userspace open multiple mdevs concurrently, allowing them to bypass the 'one
> mdev per KVM' isolation restriction since vfio_ap_mdev_set_kvm() won't see
> the other devices in the list yet?
>
>> if (ret)
>> goto err_put_vdev;
>> - matrix_mdev->req_trigger = NULL;
>> - matrix_mdev->cfg_chg_trigger = NULL;
> [Severity: High]
> This is a pre-existing issue, but since you are touching the eventfd triggers
> here, are they properly cleaned up when the device is closed?
>
> Userspace can set IRQ triggers via VFIO_DEVICE_SET_IRQS, which calls
> eventfd_ctx_fdget() and takes a reference. If the user closes the device
> without unregistering the IRQs, shouldn't vfio_ap_mdev_close_device() or
> vfio_ap_mdev_remove() call eventfd_ctx_put() for req_trigger and
> cfg_chg_trigger to prevent a memory and file descriptor leak?
The other concerns are fixed in this series, but this concern is not. This
needs to be fixed.
>
>> +
>> + /*
>> + * Take the matrix_dev->guests_lock mutex before adding the matrix_mdev
>> + * to the mdev_list. All functions that traverse the list must also hold
>> + * this lock to guard against additions to or removals from the list
>> + * while it is being traversed.
>> + */
>> + mutex_lock(&matrix_dev->guests_lock);
>> dev_set_drvdata(&mdev->dev, matrix_mdev);
>> - mutex_lock(&matrix_dev->mdevs_lock);
>> list_add(&matrix_mdev->node, &matrix_dev->mdev_list);
>> - mutex_unlock(&matrix_dev->mdevs_lock);
>> + mutex_unlock(&matrix_dev->guests_lock);
>> return 0;
> [ ... ]
>
>> @@ -2316,6 +2323,7 @@ static ssize_t status_show(struct device *dev,
>> struct ap_matrix_mdev *matrix_mdev;
>> struct ap_device *apdev = to_ap_dev(dev);
>>
>> + mutex_lock(&matrix_dev->guests_lock);
>> mutex_lock(&matrix_dev->mdevs_lock);
>> q = dev_get_drvdata(&apdev->device);
> [Severity: Critical]
> This is a pre-existing issue, but is it possible for dev_get_drvdata() to
> return a NULL pointer here if the status sysfs file is read concurrently
> with device probing?
>
> During vfio_ap_mdev_probe_queue(), sysfs_create_group() creates the status
> attribute before dev_set_drvdata() initializes the driver data. Can a
> concurrent read of the status file fetch a NULL pointer in status_show() and
> pass it to vfio_ap_mdev_for_queue(), causing a crash when it dereferences
> q->apqn?
>
>> matrix_mdev = vfio_ap_mdev_for_queue(q);
>> @@ -2343,6 +2351,7 @@ static ssize_t status_show(struct device *dev,
>> }
>>
>> mutex_unlock(&matrix_dev->mdevs_lock);
>> + mutex_unlock(&matrix_dev->guests_lock);
>>
>> return nchars;
>> }
next prev parent reply other threads:[~2026-08-12 18:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 17:09 [PATCH v4 0/9] s390/vfio-ap: Fix bugs in vfio_ap device driver callback functions Anthony Krowiak
2026-08-12 17:09 ` [PATCH v4 1/9] s390/vfio-ap: Fix stale do_remove flag across iterations in vfio_ap_mdev_cfg_remove Anthony Krowiak
2026-08-12 17:22 ` sashiko-bot
2026-08-12 17:09 ` [PATCH v4 2/9] s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL Anthony Krowiak
2026-08-12 17:28 ` sashiko-bot
2026-08-12 17:09 ` [PATCH v4 3/9] s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects Anthony Krowiak
2026-08-12 17:28 ` sashiko-bot
2026-08-12 18:25 ` Anthony Krowiak [this message]
2026-08-12 17:09 ` [PATCH v4 4/9] s390/vfio-ap: Fix required lock not held during update of ap_matrix_mdev object Anthony Krowiak
2026-08-12 17:24 ` sashiko-bot
2026-08-12 17:09 ` [PATCH v4 5/9] s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove Anthony Krowiak
2026-08-12 17:19 ` sashiko-bot
2026-08-12 17:09 ` [PATCH v4 6/9] s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap Anthony Krowiak
2026-08-12 17:17 ` sashiko-bot
2026-08-12 17:09 ` [PATCH v4 7/9] s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain removed Anthony Krowiak
2026-08-12 17:24 ` sashiko-bot
2026-08-12 17:09 ` [PATCH v4 8/9] s390/vfio-ap: Fix NULL deref in status_show() during queue probe Anthony Krowiak
2026-08-12 17:27 ` sashiko-bot
2026-08-12 17:58 ` Matthew Rosato
2026-08-12 18:16 ` Anthony Krowiak
2026-08-12 18:56 ` Matthew Rosato
2026-08-12 17:09 ` [PATCH v4 9/9] s390/vfio-ap: Fix memory leak when queue removed from host AP config Anthony Krowiak
2026-08-12 17:38 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cb9ff85c-b7a3-4e0c-9250-60a553819c53@linux.ibm.com \
--to=akrowiak@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.vom \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.