[GIT PULL 0/5] KVM: s390: Fixes for 7.2

[GIT PULL 0/5] KVM: s390: Fixes for 7.2

[Christian Borntraeger]

From: Christian Borntraeger <borntraeger@linux.ibm.com>

Paolo,

please pull the following changes since commit 8cdeaa50eae8dad34885515f62559ee83e7e8dda:

  Linux 7.2-rc2 (2026-07-05 14:44:06 -1000)

from the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git  tags/kvm-s390-master-7.2-1

for you to fetch changes up to 3e3aa6da87d30a0064a17b836685cd43c90a3572:

  KVM: s390: pci: Fix handling of AIF enable without AISB (2026-07-09 16:23:10 +0200)

----------------------------------------------------------------
KVM: s390: Fixes for 7.2

- more gmap KVM memory management fixes
- PCI passthru fixes

----------------------------------------------------------------
Claudio Imbrenda (3):
      KVM: s390: vsie: Avoid potential deadlock with real spaces
      KVM: s390: Fix dat_crste_walk_range() early return
      KVM: s390: Improve kvm_s390_vm_stop_migration()

Haoxiang Li (1):
      KVM: s390: pci: Fix GISC refcount leak on AIF enable failure

Matthew Rosato (1):
      KVM: s390: pci: Fix handling of AIF enable without AISB

 arch/s390/kvm/dat.c      |  2 ++
 arch/s390/kvm/gmap.c     |  7 ++++++-
 arch/s390/kvm/kvm-s390.c |  6 ++++--
 arch/s390/kvm/pci.c      | 12 +++++++++---
 4 files changed, 21 insertions(+), 6 deletions(-)

[GIT PULL 1/5] KVM: s390: pci: Fix GISC refcount leak on AIF enable failure

[Christian Borntraeger]

From: Haoxiang Li <haoxiang_li2024@163.com>

kvm_s390_gisc_register() registers the guest ISC before pinning
the guest interrupt forwarding pages and allocating the AISB bit.
If any of the later setup steps fails, the function unwinds the
pinned pages and other local state, but does not unregister the
GISC reference. Add the missing kvm_s390_gisc_unregister() to the
error unwind path.

Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Tested-by: Matthew Rosato <mjrosato@linux.ibm.com>
Acked-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260624061910.2794734-1-haoxiang_li2024@163.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
---
 arch/s390/kvm/pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/s390/kvm/pci.c b/arch/s390/kvm/pci.c
index 5b075c38998e3..686113be05309 100644
--- a/arch/s390/kvm/pci.c
+++ b/arch/s390/kvm/pci.c
@@ -328,6 +328,7 @@ static int kvm_s390_pci_aif_enable(struct zpci_dev *zdev, struct zpci_fib *fib,
 unpin1:
 	unpin_user_page(aibv_page);
 out:
+	kvm_s390_gisc_unregister(kvm, fib->fmt0.isc);
 	return rc;
 }
 
-- 
2.55.0

Re: [GIT PULL 1/5] KVM: s390: pci: Fix GISC refcount leak on AIF enable failure

[sashiko-bot]

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

Pre-existing issues:
- [Critical] Repeated calls to the `KVM_S390_ZPCIOP_REG_AEN` ioctl leak resources and cause Use-After-Free.
- [High] `account_mem` and `unaccount_mem` leak `struct user_struct` reference counts and use wrong accounting context.
- [High] `kvm_s390_pci_aif_enable` silently fails on memory accounting or bit allocation failure.
- [High] Resource leak on `kvm_zpci_set_airq` hardware setup failure.
- [High] Missing memory unaccounting on bit allocation failure.
- [High] Unchecked `airq_iv_create()` return value leads to kernel panic.
--

--- Patch [1]: [GIT PULL 1/5] KVM: s390: pci: Fix GISC refcount leak on AIF enable failure ---
commit 2781de8fecc1ddfd2641c260ff20fd3cfb663715
Author: Haoxiang Li <haoxiang_li2024@163.com>
Subject: KVM: s390: pci: Fix GISC refcount leak on AIF enable failure

This commit fixes a reference count leak of the guest ISC in the error
handling path of kvm_s390_pci_aif_enable(). It ensures that if setup fails,
kvm_s390_gisc_unregister() is called to properly release the GISC reference.

> diff --git a/arch/s390/kvm/pci.c b/arch/s390/kvm/pci.c
> index 5b075c38998e3..686113be05309 100644
> --- a/arch/s390/kvm/pci.c
> +++ b/arch/s390/kvm/pci.c
> @@ -328,6 +328,7 @@ static int kvm_s390_pci_aif_enable(struct zpci_dev *zdev, struct zpci_fib *fib,
>  unpin1:
>  	unpin_user_page(aibv_page);
>  out:
> +	kvm_s390_gisc_unregister(kvm, fib->fmt0.isc);
>  	return rc;
>  }

[Severity: High]
This is a pre-existing issue, but does a failure in kvm_zpci_set_airq() leak
all previously allocated resources?

Looking at the lines just above this diff in kvm_s390_pci_aif_enable():

    rc = kvm_zpci_set_airq(zdev);
    return rc;

unlock:
    mutex_unlock(&aift->aift_lock);

Returning rc directly bypasses the unlock, unpin2, unpin1, and out labels.
This skips all resource cleanup, including the new kvm_s390_gisc_unregister()
call added by this patch.


[Severity: High]
This isn't a bug introduced by this patch, but is there a missing call to
unaccount_mem() in the error path?

Looking at the error handling in kvm_s390_pci_aif_enable():

unlock:
    mutex_unlock(&aift->aift_lock);
unpin2:

If airq_iv_alloc_bit() fails and jumps to unlock, it unwinds the pinned pages
but leaves the memory accounted for, potentially leaking the locked_vm limit.


[Severity: High]
This is a pre-existing issue, but do these error paths return 0 to userspace
instead of an error code?

In kvm_s390_pci_aif_enable(), when memory accounting or bit allocation fails:

    if (account_mem(pcount))
        goto unpin2;
    ...
    bit = airq_iv_alloc_bit(aift->sbv);
    if (bit == -1UL)
        goto unlock;

When jumping to the cleanup labels, rc does not appear to be set to a negative
value like -ENOMEM or -ENOSPC. Since rc is initialized to 0, this would
silently mask the internal failure.


[Severity: Critical]
This isn't a bug introduced by this patch, but what happens if userspace calls
the KVM_S390_ZPCIOP_REG_AEN ioctl multiple times?

In kvm_s390_pci_aif_enable():

    zdev->aisb = bit; /* store the summary bit number */
    zdev->aibv = airq_iv_create(...);
    ...
    aift->kzdev[zdev->aisb] = zdev->kzdev;

It looks like this blindly allocates new resources and overwrites zdev->aibv
and zdev->aisb without cleaning up any previous allocations. The old aisb index
remains populated in aift->kzdev, which might lead to a use-after-free when
the device is unregistered.


[Severity: High]
This is a pre-existing issue, but can airq_iv_create() return NULL here?

In kvm_s390_pci_aif_enable():

    zdev->aibv = airq_iv_create(msi_vecs, AIRQ_IV_DATA | ...

If it fails due to memory pressure, it seems zdev->aibv becomes NULL. Later,
zdev is passed to kvm_zpci_set_airq() which does this:

    fib.fmt0.noi = airq_iv_end(zdev->aibv);
    fib.fmt0.aibv = virt_to_phys(zdev->aibv->vector);

This unconditionally dereferences the unchecked pointer, potentially causing
a crash.


[Severity: High]
This isn't a bug introduced by this patch, but do account_mem() and
unaccount_mem() leak the user_struct reference?

arch/s390/kvm/pci.c:account_mem() {
    ...
    struct user_struct *user = get_uid(current_user());
    ...
}

I see get_uid() increments the refcount, but there doesn't appear to be a
matching free_uid() on success or error.

Additionally, in unaccount_mem():

arch/s390/kvm/pci.c:unaccount_mem() {
    ...
    struct user_struct *user = get_uid(current_user());
    ...
}

Calling current_user() might un-account from a different process or kernel
thread if deregistration happens asynchronously.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727095359.107671-2-borntraeger@de.ibm.com?part=1

[GIT PULL 2/5] KVM: s390: vsie: Avoid potential deadlock with real spaces

[Christian Borntraeger]

From: Claudio Imbrenda <imbrenda@linux.ibm.com>

The natural lock ordering is mmu_lock -> children_lock, but in
gmap_create_shadow() the reverse order is used when handling shadowing
of real address spaces.

Convert the inner locking of kvm->mmu_lock to a trylock; return -EAGAIN
if the lock is busy, and let the caller try again.

This path is not expected to happen in real-life scenarios, so its
performance is not important.

Fixes: a2c17f9270cc ("KVM: s390: New gmap code")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
---
 arch/s390/kvm/gmap.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/s390/kvm/gmap.c b/arch/s390/kvm/gmap.c
index 298fbaecec28d..8abb4f55b306b 100644
--- a/arch/s390/kvm/gmap.c
+++ b/arch/s390/kvm/gmap.c
@@ -1374,8 +1374,13 @@ struct gmap *gmap_create_shadow(struct kvm_s390_mmu_cache *mc, struct gmap *pare
 			/* Only allow one real-space gmap shadow. */
 			list_for_each_entry(sg, &parent->children, list) {
 				if (sg->guest_asce.r) {
-					scoped_guard(write_lock, &parent->kvm->mmu_lock)
+					if (write_trylock(&parent->kvm->mmu_lock)) {
 						gmap_unshadow(sg);
+						write_unlock(&parent->kvm->mmu_lock);
+					} else {
+						gmap_put(new);
+						return ERR_PTR(-EAGAIN);
+					}
 					break;
 				}
 			}
-- 
2.55.0

Re: [GIT PULL 2/5] KVM: s390: vsie: Avoid potential deadlock with real spaces

[sashiko-bot]

> From: Claudio Imbrenda <imbrenda@linux.ibm.com>
> 
> The natural lock ordering is mmu_lock -> children_lock, but in
> gmap_create_shadow() the reverse order is used when handling shadowing
> of real address spaces.
> 
> Convert the inner locking of kvm->mmu_lock to a trylock; return -EAGAIN
> if the lock is busy, and let the caller try again.
> 
> This path is not expected to happen in real-life scenarios, so its
> performance is not important.
> 
> Fixes: a2c17f9270cc ("KVM: s390: New gmap code")
> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727095359.107671-3-borntraeger@de.ibm.com?part=1

[GIT PULL 3/5] KVM: s390: Fix dat_crste_walk_range() early return

[Christian Borntraeger]

From: Claudio Imbrenda <imbrenda@linux.ibm.com>

If a walk entry handler for a lower level returns a value,
dat_crste_walk_range() will not return immediately, but instead loop
again and move to the next entry.

This means that some entries are potentially skipped, and early return
is ignored. Skipped entries might lead to all kinds of issues, given
that the caller expects them to not be skipped. Early return is often
used to interrupt a walk when a rescheduling is needed; if it is
ignored it can lead to stalls.

Fix by breaking from the loop immediately if the walk to a lower level
returned non-zero.

Fixes: 2db149a0a6c5 ("KVM: s390: KVM page table management functions: walks")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
---
 arch/s390/kvm/dat.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/s390/kvm/dat.c b/arch/s390/kvm/dat.c
index 5f1960ec982d0..ed4259d176295 100644
--- a/arch/s390/kvm/dat.c
+++ b/arch/s390/kvm/dat.c
@@ -570,6 +570,8 @@ static long dat_crste_walk_range(gfn_t start, gfn_t end, struct crst_table *tabl
 			else if (walk->ops->pte_entry)
 				rc = dat_pte_walk_range(max(start, cur), min(end, next),
 							dereference_pmd(crste.pmd), walk);
+			if (rc)
+				break;
 		}
 	}
 	return rc;
-- 
2.55.0

Re: [GIT PULL 3/5] KVM: s390: Fix dat_crste_walk_range() early return

[sashiko-bot]

> From: Claudio Imbrenda <imbrenda@linux.ibm.com>
> 
> If a walk entry handler for a lower level returns a value,
> dat_crste_walk_range() will not return immediately, but instead loop
> again and move to the next entry.
> 
> This means that some entries are potentially skipped, and early return
> is ignored. Skipped entries might lead to all kinds of issues, given
> that the caller expects them to not be skipped. Early return is often
> used to interrupt a walk when a rescheduling is needed; if it is
> ignored it can lead to stalls.
> 
> Fix by breaking from the loop immediately if the walk to a lower level
> returned non-zero.
> 
> Fixes: 2db149a0a6c5 ("KVM: s390: KVM page table management functions: walks")
> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727095359.107671-4-borntraeger@de.ibm.com?part=1

[GIT PULL 4/5] KVM: s390: Improve kvm_s390_vm_stop_migration()

[Christian Borntraeger]

From: Claudio Imbrenda <imbrenda@linux.ibm.com>

There is no need to clear cmma-dirty state if the VM is not using CMMA.

Skip the CMMA-related code if CMMA is not in use.

Fixes: 6cfd47f91f6a ("KVM: s390: Fix cmma dirty tracking")
Fixes: 190df4a212a7 ("KVM: s390: CMMA tracking, ESSA emulation, migration mode")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
---
 arch/s390/kvm/kvm-s390.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 23c817595e28d..150b5dd2170e2 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -1280,8 +1280,10 @@ static int kvm_s390_vm_stop_migration(struct kvm *kvm)
 	 * PGSTEs might have cmma_d set.
 	 */
 	WRITE_ONCE(kvm->arch.migration_mode, 0);
-	if (kvm->arch.use_cmma)
-		kvm_s390_sync_request_broadcast(kvm, KVM_REQ_STOP_MIGRATION);
+	if (!kvm->arch.use_cmma)
+		return 0;
+
+	kvm_s390_sync_request_broadcast(kvm, KVM_REQ_STOP_MIGRATION);
 	/* Clear cmma_d on all existing PGSTEs and set cmma_dirty_pages to 0. */
 	gmap_set_cmma_all_clean(kvm->arch.gmap);
 	atomic64_set(&kvm->arch.cmma_dirty_pages, 0);
-- 
2.55.0

Re: [GIT PULL 4/5] KVM: s390: Improve kvm_s390_vm_stop_migration()

[sashiko-bot]

> From: Claudio Imbrenda <imbrenda@linux.ibm.com>
> 
> There is no need to clear cmma-dirty state if the VM is not using CMMA.
> 
> Skip the CMMA-related code if CMMA is not in use.
> 
> Fixes: 6cfd47f91f6a ("KVM: s390: Fix cmma dirty tracking")
> Fixes: 190df4a212a7 ("KVM: s390: CMMA tracking, ESSA emulation, migration mode")
> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727095359.107671-5-borntraeger@de.ibm.com?part=1

[GIT PULL 5/5] KVM: s390: pci: Fix handling of AIF enable without AISB

[Christian Borntraeger]

From: Matthew Rosato <mjrosato@linux.ibm.com>

When a guest seeks to register IRQs without a summary bit specified,
ensure that the associated GAITE then stores 0 for the guest AISB
location instead of virt_to_phys(page_address(NULL)).

Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding")
Cc: stable@vger.kernel.org
Reviewed-by: Farhan Ali <alifm@linux.ibm.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
---
 arch/s390/kvm/pci.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/s390/kvm/pci.c b/arch/s390/kvm/pci.c
index 686113be05309..720bb58cabe2e 100644
--- a/arch/s390/kvm/pci.c
+++ b/arch/s390/kvm/pci.c
@@ -300,9 +300,14 @@ static int kvm_s390_pci_aif_enable(struct zpci_dev *zdev, struct zpci_fib *fib,
 
 	gaite->gisc = fib->fmt0.isc;
 	gaite->count++;
-	gaite->aisbo = fib->fmt0.aisbo;
-	gaite->aisb = virt_to_phys(page_address(aisb_page) + (fib->fmt0.aisb &
-							      ~PAGE_MASK));
+	if (fib->fmt0.sum == 1) {
+		gaite->aisbo = fib->fmt0.aisbo;
+		gaite->aisb = virt_to_phys(page_address(aisb_page) +
+					   (fib->fmt0.aisb & ~PAGE_MASK));
+	} else {
+		gaite->aisbo = 0;
+		gaite->aisb = 0;
+	}
 	aift->kzdev[zdev->aisb] = zdev->kzdev;
 	spin_unlock_irq(&aift->gait_lock);
 
-- 
2.55.0

Re: [GIT PULL 5/5] KVM: s390: pci: Fix handling of AIF enable without AISB

[sashiko-bot]

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

Pre-existing issues:
- [Critical] Missing page boundary check allows unprivileged guest to trigger out-of-bounds hardware DMA writes.
- [High] Missing error code assignments cause silent failures and memory accounting leaks.
- [High] Missing NULL check on the return value of airq_iv_create() leads to an unconditional host kernel panic.
- [High] Repeatedly enabling AIF on an already-registered device causes state corruption and massive resource leaks.
- [High] Kernel resources are not rolled back if the PCI hardware configuration (kvm_zpci_set_airq) fails.
- [High] account_mem() and unaccount_mem() perpetually leak user_struct reference counts.
- [High] The guest ISC reference count leaks on error paths, leading to a 32-bit integer overflow and Denial of Service.
--

--- Patch [1]: [GIT PULL 5/5] KVM: s390: pci: Fix handling of AIF enable without AISB ---
commit d999e1412ad1f5b8348f25eacbb5dfb9be451bb1
Author: Matthew Rosato <mjrosato@linux.ibm.com>

KVM: s390: pci: Fix handling of AIF enable without AISB
    
This commit modifies the KVM s390 PCI interrupt forwarding (AIF) enablement. 
It ensures that when a guest registers IRQs without a summary bit (AISB), the 
guest AISB location is explicitly set to 0 rather than a potentially invalid 
physical address derived from a NULL pointer.

> diff --git a/arch/s390/kvm/pci.c b/arch/s390/kvm/pci.c
> index 5b075c38998e3..dc748cde4703b 100644
> --- a/arch/s390/kvm/pci.c
> +++ b/arch/s390/kvm/pci.c
> @@ -300,9 +300,14 @@ static int kvm_s390_pci_aif_enable(struct zpci_dev *zdev, struct zpci_fib *fib,
>  
>  	gaite->gisc = fib->fmt0.isc;
>  	gaite->count++;
> -	gaite->aisbo = fib->fmt0.aisbo;
> -	gaite->aisb = virt_to_phys(page_address(aisb_page) + (fib->fmt0.aisb &
> -							      ~PAGE_MASK));
> +	if (fib->fmt0.sum == 1) {
> +		gaite->aisbo = fib->fmt0.aisbo;
> +		gaite->aisb = virt_to_phys(page_address(aisb_page) +
> +					   (fib->fmt0.aisb & ~PAGE_MASK));
> +	} else {
> +		gaite->aisbo = 0;
> +		gaite->aisb = 0;
> +	}
>  	aift->kzdev[zdev->aisb] = zdev->kzdev;
>  	spin_unlock_irq(&aift->gait_lock);

[Severity: Critical]
This is a pre-existing issue, but does this lack of boundary checking allow
out-of-bounds hardware DMA writes?

Looking at kvm_s390_pci_aif_enable(), the code pins exactly one page for the
guest's Adapter Interruption Broadcast Vector (AIBV):

arch/s390/kvm/pci.c:kvm_s390_pci_aif_enable() {
    ...
	npages = pin_user_pages_fast(hva, 1, FOLL_WRITE | FOLL_LONGTERM, pages);
    ...
	gaddr = page_to_phys(aibv_page) + (fib->fmt0.aibv & ~PAGE_MASK);
    ...
}

If the guest supplies an offset near the end of the page and a large number
of MSI vectors, could the hardware DMA overflow the single pinned page and
corrupt adjacent unpinned physical memory?

[Severity: High]
This is a pre-existing issue, but does this error path leak the guest ISC
reference count?

arch/s390/kvm/pci.c:kvm_s390_pci_aif_enable() {
    ...
	gisc = kvm_s390_gisc_register(kvm, fib->fmt0.isc);
	if (gisc < 0)
		return gisc;
    ...
	npages = pin_user_pages_fast(hva, 1, FOLL_WRITE | FOLL_LONGTERM, pages);
	srcu_read_unlock(&kvm->srcu, idx);
	if (npages < 1) {
		rc = -EIO;
		goto out;
	}
    ...
out:
	return rc;
}

If pin_user_pages_fast() fails, the function branches to the out label but
appears to omit calling kvm_s390_gisc_unregister(). Could this lead to a
32-bit integer overflow on gi->alert.ref_count[gisc]?

[Severity: High]
This is a pre-existing issue, but do these error paths silently fail and leak
memory accounting limits?

arch/s390/kvm/pci.c:kvm_s390_pci_aif_enable() {
    ...
	if (account_mem(pcount))
		goto unpin2;
    ...
	bit = airq_iv_alloc_bit(aift->sbv);
	if (bit == -1UL)
		goto unlock;
    ...
}

If account_mem() or airq_iv_alloc_bit() fail, the function jumps to cleanup
labels but returns rc, which is initialized to 0. 

Additionally, in the airq_iv_alloc_bit() error path, unaccount_mem() appears
to be missing entirely. Does this silently leak the locked_vm memory
accounting?

[Severity: High]
This is a pre-existing issue, but what prevents a guest from repeatedly calling
KVM_S390_ZPCIOP_REG_AEN for the same device?

arch/s390/kvm/pci.c:kvm_s390_pci_aif_enable() {
    ...
	zdev->aisb = bit; /* store the summary bit number */
	zdev->aibv = airq_iv_create(msi_vecs, AIRQ_IV_DATA |
    ...
}

If userspace calls KVM_S390_ZPCIOP_REG_AEN multiple times for the same PCI
device, the function appears to lack a check verifying if zdev->aibv is
already set. 

Could this blindly allocate and pin new resources while unconditionally
overwriting the existing pointers, permanently leaking the previously
pinned pages and airq_iv structures?

[Severity: High]
This is a pre-existing issue, but does this code risk a NULL pointer
dereference if airq_iv_create() fails?

arch/s390/kvm/pci.c:kvm_s390_pci_aif_enable() {
    ...
	zdev->aibv = airq_iv_create(msi_vecs, AIRQ_IV_DATA |
				    AIRQ_IV_BITLOCK |
				    AIRQ_IV_GUESTVEC,
				    phys_to_virt(fib->fmt0.aibv));
    ...
}

If airq_iv_create() returns NULL in out-of-memory conditions, the result is
assigned to zdev->aibv without validation. 

Could this lead to an unconditional host kernel panic when
kvm_zpci_set_airq() subsequently dereferences it via airq_iv_end(zdev->aibv)?

[Severity: High]
This is a pre-existing issue, but are kernel resources permanently leaked if
the hardware configuration fails?

arch/s390/kvm/pci.c:kvm_s390_pci_aif_enable() {
    ...
	/* Issue the clp to setup the irq now */
	rc = kvm_zpci_set_airq(zdev);
	return rc;

unlock:
    ...
}

If kvm_zpci_set_airq() returns an error because the hardware rejects the CLP
instruction, the function returns directly. Should it use the cleanup labels
to avoid leaking pinned guest memory pages and GISC registrations?

[Severity: High]
This is a pre-existing issue, but do account_mem() and unaccount_mem()
perpetually leak user_struct references?

arch/s390/kvm/pci.c:account_mem() {
    ...
	struct user_struct *user = get_uid(current_user());
    ...
}

Both functions call get_uid(current_user()), which increments the reference
count. However, neither function appears to ever call free_uid() to release
the acquired reference.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727095359.107671-6-borntraeger@de.ibm.com?part=1

Re: [GIT PULL 0/5] KVM: s390: Fixes for 7.2

[Christian Borntraeger]

Am 27.07.26 um 11:53 schrieb Christian Borntraeger:
> From: Christian Borntraeger <borntraeger@linux.ibm.com>
> 
> Paolo,
> 
> please pull the following changes since commit 8cdeaa50eae8dad34885515f62559ee83e7e8dda:
> 
>    Linux 7.2-rc2 (2026-07-05 14:44:06 -1000)
> 
> from the Git repository at:
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git  tags/kvm-s390-master-7.2-1
> 
> for you to fetch changes up to 3e3aa6da87d30a0064a17b836685cd43c90a3572:
> 
>    KVM: s390: pci: Fix handling of AIF enable without AISB (2026-07-09 16:23:10 +0200)
> 
> ----------------------------------------------------------------
> KVM: s390: Fixes for 7.2
> 
> - more gmap KVM memory management fixes
> - PCI passthru fixes

Please ignore this, I was running my commands in an old folder.......
will send properly in a minute.

[GIT PULL 0/5] KVM: s390: Fixes for 7.2

[Christian Borntraeger]

From: Christian Borntraeger <borntraeger@linux.ibm.com>

Paolo,

please pull the following changes since commit 8cdeaa50eae8dad34885515f62559ee83e7e8dda:

  Linux 7.2-rc2 (2026-07-05 14:44:06 -1000)

from the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git  tags/kvm-s390-master-7.2-1

for you to fetch changes up to 3e3aa6da87d30a0064a17b836685cd43c90a3572:

  KVM: s390: pci: Fix handling of AIF enable without AISB (2026-07-09 16:23:10 +0200)

----------------------------------------------------------------
KVM: s390: Fixes for 7.2

- more gmap KVM memory management fixes
- PCI passthru fixes

----------------------------------------------------------------
Claudio Imbrenda (3):
      KVM: s390: vsie: Avoid potential deadlock with real spaces
      KVM: s390: Fix dat_crste_walk_range() early return
      KVM: s390: Improve kvm_s390_vm_stop_migration()

Haoxiang Li (1):
      KVM: s390: pci: Fix GISC refcount leak on AIF enable failure

Matthew Rosato (1):
      KVM: s390: pci: Fix handling of AIF enable without AISB

 arch/s390/kvm/dat.c      |  2 ++
 arch/s390/kvm/gmap.c     |  7 ++++++-
 arch/s390/kvm/kvm-s390.c |  6 ++++--
 arch/s390/kvm/pci.c      | 12 +++++++++---
 4 files changed, 21 insertions(+), 6 deletions(-)

[GIT PULL 2/5] KVM: s390: vsie: Avoid potential deadlock with real spaces

[Christian Borntraeger]

From: Claudio Imbrenda <imbrenda@linux.ibm.com>

The natural lock ordering is mmu_lock -> children_lock, but in
gmap_create_shadow() the reverse order is used when handling shadowing
of real address spaces.

Convert the inner locking of kvm->mmu_lock to a trylock; return -EAGAIN
if the lock is busy, and let the caller try again.

This path is not expected to happen in real-life scenarios, so its
performance is not important.

Fixes: a2c17f9270cc ("KVM: s390: New gmap code")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
---
 arch/s390/kvm/gmap.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/s390/kvm/gmap.c b/arch/s390/kvm/gmap.c
index 298fbaecec28d..8abb4f55b306b 100644
--- a/arch/s390/kvm/gmap.c
+++ b/arch/s390/kvm/gmap.c
@@ -1374,8 +1374,13 @@ struct gmap *gmap_create_shadow(struct kvm_s390_mmu_cache *mc, struct gmap *pare
 			/* Only allow one real-space gmap shadow. */
 			list_for_each_entry(sg, &parent->children, list) {
 				if (sg->guest_asce.r) {
-					scoped_guard(write_lock, &parent->kvm->mmu_lock)
+					if (write_trylock(&parent->kvm->mmu_lock)) {
 						gmap_unshadow(sg);
+						write_unlock(&parent->kvm->mmu_lock);
+					} else {
+						gmap_put(new);
+						return ERR_PTR(-EAGAIN);
+					}
 					break;
 				}
 			}
-- 
2.55.0