From: sashiko-bot@kernel.org
To: "Anthony Krowiak" <akrowiak@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, "Vasily Gorbik" <gor@linux.ibm.com>,
kvm@vger.kernel.org, "Alexander Gordeev" <agordeev@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>
Subject: Re: [PATCH] s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL
Date: Fri, 07 Aug 2026 15:18:09 +0000 [thread overview]
Message-ID: <20260807151809.CEF971F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260807145416.322916-1-akrowiak@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Incorrect bitwise operation `bitmap_andnot` used instead of `bitmap_and` for control domains in `vfio_ap_mdev_cfg_remove`, preventing removal of unplugged domains.
--
--- Patch [1]: [PATCH] s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL ---
commit 7ae73def648a068715a8cdb4bf574ac5755f8e77
Author: Anthony Krowiak <akrowiak@linux.ibm.com>
s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL
This commit adds NULL pointer checks for matrix_mdev->kvm prior to taking
the kvm->lock mutex in the configuration change and scan complete callbacks.
This prevents a NULL pointer dereference when the matrix mdev has no
associated KVM instance.
Cc: stable@vger.kernel.org
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> index 44b3a1dcc1b36..a0b7c37fee281 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -2606,7 +2606,15 @@ static void vfio_ap_mdev_cfg_remove(unsigned long *ap_remove,
> int do_remove = 0;
>
> list_for_each_entry(matrix_mdev, &matrix_dev->mdev_list, node) {
> - mutex_lock(&matrix_mdev->kvm->lock);
> + /*
> + * If the mdev is attached to a KVM guest, we will need to
> + * hold the KVM lock in order to update the guest's AP
> + * configuration if any adapters, domains or control domains
> + * have been removed.
> + */
> + if (matrix_mdev->kvm)
> + mutex_lock(&matrix_mdev->kvm->lock);
> +
> mutex_lock(&matrix_dev->mdevs_lock);
>
> do_remove |= bitmap_and(aprem, ap_remove,
[Severity: High]
This is a pre-existing issue, but I noticed a potential logic flaw just
below this context in vfio_ap_mdev_cfg_remove() within
drivers/s390/crypto/vfio_ap_ops.c.
Does the control domain removal incorrectly use bitmap_andnot() instead of
bitmap_and()?
When a host administrator or hypervisor unplugs a control domain, the code
evaluates the removed domains using:
do_remove |= bitmap_andnot(cdrem, cd_remove,
matrix_mdev->matrix.adm,
AP_DOMAINS);
Since this evaluates to cd_remove & ~matrix_mdev->matrix.adm, doesn't this
mean assigned domains that were removed from the host will resolve to 0?
Could this prevent explicitly unplugged control domains from being removed
from the KVM guest, allowing it to retain access to hardware it shouldn't
have?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260807145416.322916-1-akrowiak@linux.ibm.com?part=1
next prev parent reply other threads:[~2026-08-07 15:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 14:54 [PATCH] s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL Anthony Krowiak
2026-08-07 15:18 ` sashiko-bot [this message]
2026-08-07 22:24 ` Anthony Krowiak
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=20260807151809.CEF971F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=akrowiak@linux.ibm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox