Re: [PATCH v3 3/8] KVM: s390: Zero initialize irq in reinject_machine_check

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Calling kfree() on a stack-allocated variable `inti` when injecting a floating machine check leads to a kernel panic.
--

--- Patch [3]: [PATCH v3 3/8] KVM: s390: Zero initialize irq in reinject_machine_check ---
commit 318473328452694fe22802ec70c8f2cf0f840578
Author: Christian Borntraeger <borntraeger@linux.ibm.com>

KVM: s390: Zero initialize irq in reinject_machine_check

This commit zero-initializes the on-stack struct kvm_s390_irq in
kvm_s390_reinject_machine_check(). This prevents uninitialized memory from
being copied into the vcpu local interrupt state and reaching the guest or
userspace.

> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
> index 23f0e0821474a..009d6a845d598 100644
> --- a/arch/s390/kvm/interrupt.c
> +++ b/arch/s390/kvm/interrupt.c
> @@ -3109,7 +3109,7 @@ void kvm_s390_reinject_machine_check(struct kvm_vcpu *vcpu,
>  				     struct mcck_volatile_info *mcck_info)
>  {
>  	struct kvm_s390_interrupt_info inti;

[Severity: High]
This is a pre-existing issue, but does this stack-allocated variable lead to
a kernel panic during floating machine check injection?

If mci.ck is set, this function passes the stack-allocated inti pointer to
__inject_vm():

	if (mci.ck) {
		/* Inject the floating machine check */
		inti.type = KVM_S390_MCHK;
		rc = __inject_vm(vcpu->kvm, &inti);
	}

__inject_vm() then calls __inject_float_mchk(), which unconditionally calls
kfree() on the provided pointer:

arch/s390/kvm/interrupt.c:__inject_float_mchk() {
    ...
    kfree(inti);
    ...
}

Will this cause a panic when kfree() attempts to free the local stack
pointer?

> -	struct kvm_s390_irq irq;
> +	struct kvm_s390_irq irq = {};
[ ... ]

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