Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: kvmarm@lists.linux.dev, Joey Gouly <joey.gouly@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH] KVM: arm64: Prevent access to vCPU events before init
Date: Tue, 30 Sep 2025 10:26:37 +0100	[thread overview]
Message-ID: <86v7l0z3xu.wl-maz@kernel.org> (raw)
In-Reply-To: <20250930085237.108326-1-oliver.upton@linux.dev>

On Tue, 30 Sep 2025 09:52:37 +0100,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> Another day, another syzkaller bug. KVM erroneously allows userspace to
> pend vCPU events for a vCPU that hasn't been initialized yet, leading to
> KVM interpreting a bunch of uninitialized garbage for routing /
> injecting the exception.
> 
> In one case the injection code and the hyp disagree on whether the vCPU
> has a 32bit EL1 and put the vCPU into an illegal mode for AArch64,
> tripping the BUG() in exception_target_el() during the next injection:
> 
>   kernel BUG at arch/arm64/kvm/inject_fault.c:40!
>   Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP
>   CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT
>   Hardware name: linux,dummy-virt (DT)
>   pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
>   pc : exception_target_el+0x88/0x8c
>   lr : pend_serror_exception+0x18/0x13c
>   sp : ffff800082f03a10
>   x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000
>   x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000
>   x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004
>   x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000
>   x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0
>   x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
>   x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
>   x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000
>   x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000
>   x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20
>   Call trace:
>    exception_target_el+0x88/0x8c (P)
>    kvm_inject_serror_esr+0x40/0x3b4
>    __kvm_arm_vcpu_set_events+0xf0/0x100
>    kvm_arch_vcpu_ioctl+0x180/0x9d4
>    kvm_vcpu_ioctl+0x60c/0x9f4
>    __arm64_sys_ioctl+0xac/0x104
>    invoke_syscall+0x48/0x110
>    el0_svc_common.constprop.0+0x40/0xe0
>    do_el0_svc+0x1c/0x28
>    el0_svc+0x34/0xf0
>    el0t_64_sync_handler+0xa0/0xe4
>    el0t_64_sync+0x198/0x19c
>   Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)
> 
> Reject the ioctls outright as no sane VMM would call these before
> KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been
> thrown away by the eventual reset of the vCPU's state.
> 
> Cc: stable@vger.kernel.org # 6.17
> Fixes: b7b27facc7b5 ("arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS")
> Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
> ---
> 
> While the blamed commit is indeed broken, only 6.17+ kernels actually
> hit the BUG() due to commit efa1368ba9f4 ("KVM: arm64: Commit exceptions
> from KVM_SET_VCPU_EVENTS immediately).
> 
>  arch/arm64/kvm/arm.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index a59b4046617c..c44357d26ee8 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -1795,6 +1795,9 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
>  	case KVM_GET_VCPU_EVENTS: {
>  		struct kvm_vcpu_events events;
>  
> +		if (!kvm_vcpu_initialized(vcpu))
> +			return -ENOEXEC;
> +
>  		if (kvm_arm_vcpu_get_events(vcpu, &events))
>  			return -EINVAL;
>  
> @@ -1806,6 +1809,9 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
>  	case KVM_SET_VCPU_EVENTS: {
>  		struct kvm_vcpu_events events;
>  
> +		if (!kvm_vcpu_initialized(vcpu))
> +			return -ENOEXEC;
> +
>  		if (copy_from_user(&events, argp, sizeof(events)))
>  			return -EFAULT;
>  
> 

LGTM, but the -ENOEXEC part will eventually need being documented.
I'll queue this now though, as it fixes an annoying bug.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2025-09-30  9:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-30  8:52 [PATCH] KVM: arm64: Prevent access to vCPU events before init Oliver Upton
2025-09-30  9:26 ` Marc Zyngier [this message]
2025-09-30  9:28 ` Marc Zyngier

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=86v7l0z3xu.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=oliver.upton@linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=yuzenghui@huawei.com \
    /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