Re: [GIT PULL v1 17/17] KVM: s390: Introducing kvm_arch_set_irq_inatomic fast inject

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Guest-reachable WARN_ON_ONCE during memory allocation failure in `__kvm_inject_pfault_token`
- [High] Preexisting guest-triggerable WARN_ON_ONCE on interrupt queue full
--

commit 4b098d22649d526ad54d46d65ab883c23baf1ae2
Author: Douglas Freimuth <freimuth@linux.ibm.com>

KVM: s390: Introducing kvm_arch_set_irq_inatomic fast inject

This commit introduces a fast path for irq injection to prevent blocking on
the global work queue. It also converts shared resources between the fast and
slow paths to spinlocks and adds statistical counters for analysis.

Message-ID: <20260604192755.203143-4-freimuth@linux.ibm.com>

> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 9265bc73cd938..dc9c7451fe979 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c

[ ... ]

> @@ -4429,19 +4439,28 @@ int kvm_s390_try_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_tod_clo
>  }
>  
>  static void __kvm_inject_pfault_token(struct kvm_vcpu *vcpu, bool start_token,
> -				      unsigned long token)
> +				     unsigned long token)
>  {
>  	struct kvm_s390_interrupt inti;
>  	struct kvm_s390_irq irq;
> +	struct kvm_s390_interrupt_info *inti_mem = NULL;
> +	int ret = 0;
>  
>  	if (start_token) {
>  		irq.u.ext.ext_params2 = token;
>  		irq.type = KVM_S390_INT_PFAULT_INIT;
>  		WARN_ON_ONCE(kvm_s390_inject_vcpu(vcpu, &irq));
>  	} else {
> +		inti_mem = kzalloc_obj(*inti_mem, GFP_KERNEL_ACCOUNT);
> +		if (WARN_ON_ONCE(!inti_mem))
> +			return;

[Severity: High]
This isn't a bug introduced by this patch, but does this guest-reachable
assertion pose a denial of service risk? Under host memory pressure, this
allocation can fail. Since a guest can trigger async page faults (and thus
host memory allocations) by accessing swapped-out memory, an unprivileged
guest could exhaust memory limits to force this allocation to fail. This
would intentionally hit the WARN_ON_ONCE, potentially crashing the host if
panic_on_warn is enabled.

> +
>  		inti.type = KVM_S390_INT_PFAULT_DONE;
>  		inti.parm64 = token;
> -		WARN_ON_ONCE(kvm_s390_inject_vm(vcpu->kvm, &inti));
> +		ret = kvm_s390_inject_vm(vcpu->kvm, &inti, inti_mem);
> +		if (ret)
> +			kfree(inti_mem);
> +		WARN_ON_ONCE(ret);

[Severity: High]
This is a pre-existing issue, but could this assertion also be driven by a
malicious guest? A guest can trigger up to ASYNC_PF_PER_VCPU * KVM_MAX_VCPUS
async page faults by continuously accessing unmapped pages and intentionally
masking floating interrupts.

This would cause the host's floating interrupt list to hit its maximum
capacity limit, causing kvm_s390_inject_vm() to return -EBUSY and triggering
this WARN_ON_ONCE. Could this be converted to a pr_warn_once() or similar
to avoid host denial of service?

>  	}
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260615124243.187614-1-imbrenda@linux.ibm.com?part=17