From nobody Sun Feb 8 12:57:51 2026 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 92F4836E34E for ; Thu, 30 Oct 2025 18:58:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761850689; cv=none; b=CLjR2Iv/q/M2TSx5UbizYR43w0VA4PjX8J89E/jeNXnIX64Ic0RJGWyzByjCQkE0IBFAWNkfdNTMzoIqNdbkdk4GZ0pQBNq9T0jtlsO83zaW39U8BAgjmyCUjwSlFWkw++LEjy3tX5cZVf6nkvckrDfGuQAXQrxZeH2EucTPgsA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761850689; c=relaxed/simple; bh=RyA8Ri5olrt5gVUAkNvgzyYtXDsIqh0YJlOJzxYebls=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=JvuAI9uaeKD2MnI1dv/+7b+lXv1+DPEH1xcry0cyaGlkja+jxa8IcmPaXxvdYjQU9+33s5/ymX3q3+t81AV8DIJDi9EQh+4hFRrZCczgiEIeuM92UzSSTK5zwbJtJg6wgjALRc1Z8qIUnkx3w4fSZfAVS4NuhIVoSRg2dIhOTCs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=2TBzJznl; arc=none smtp.client-ip=209.85.215.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="2TBzJznl" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-b62da7602a0so1109445a12.2 for ; Thu, 30 Oct 2025 11:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1761850687; x=1762455487; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=ffdGfK3G8fFqWd4bB2Py6VDSdKdATKpCm00IZqsBSKk=; b=2TBzJznlMDlWWG7tJPryqo4r+OENiehvvBeDK5GYkQhxIj7lIOT4JdTMwTMoXivEl9 wYN0oKJ8xRwVeTSjTjOPUa6/cuSbWI/kBXpPruKqJb5Z//veei3bUVXBnBD2RzncP1O4 X8wh1lwmrOnZchmG0QweqCM6ixcAESiXNFeZkgjIb3W8vhWZMn4jB4eNdq8RQThuCYkx TxfYSonXMp9bqmGV/of7acCuonmNJzlDMa0RM7fTIxd/oJWV6xzdGHM+VZOntHk1Q128 zNx+DlLFXlazbH8C4xjm6dUiP9NnIdP0Ymj0zWHk9vj+XFTs2kYBL9bRiZxI4JDFnPCF YGZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761850687; x=1762455487; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ffdGfK3G8fFqWd4bB2Py6VDSdKdATKpCm00IZqsBSKk=; b=iPjZlxaSxg0P8rqR9wiWKWnKbJ0h6vy+/SZzgnPwM0ABjTEQ+NjqXawFUjIBFEBO/d 8nbKVKJvGzTGU1/roCTv/FO5AXHccG67/FslPV7Q7E2ZNNnr9bfKUeHIqDiLukvhlLun ndW3l2+4rQcUTSdeOUr1FeKhVA8lE3wHA+xORnVeKA7aNyk2mE40hVJhN1nke6wx7Zd6 axrRl71+gGIjFEC3578uArt6l6/5gPkaWlB9lERSlFrkK828OxWH1rhW4XfiJniii+Q1 8n2vFbljNz/OiY545hx/agyNH9/fNSYCLqG+qW7y5tf8kcDvXWnd4ovcPVqTpGrPHuVD FRlQ== X-Forwarded-Encrypted: i=1; AJvYcCWHYpsYmUHtMfQJxcCG90AY6TU1zd06tpG11Ms/SghRkKQnE9UliMO6lX9UvpbMEm1CWClkzzy2lhRMHhI=@vger.kernel.org X-Gm-Message-State: AOJu0YzDihIKnA7ZS48NYW31QBYlfjhSrwOLRBhiwGLF55ws5ZcXvLvA MnXATx1I9Z/bMwIicpDQTT9dBFRuSv3k5uzFf1dNE2ta1fgLmuAoEELEUWSE/fg+I2IiEWBnPHn WGr+NRQ== X-Google-Smtp-Source: AGHT+IF2EI2U816IX2ZBkV1AWOUJKFRBQZltZYX3ifvjPmcAGE8cExdVkbmQPbMi8HXd1Tz34n+BLWcJgeQ= X-Received: from plrd18.prod.google.com ([2002:a17:902:aa92:b0:27d:1f18:78ab]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:e746:b0:295:6e0:7b0d with SMTP id d9443c01a7336-2951a5e4b8cmr7986855ad.56.1761850686758; Thu, 30 Oct 2025 11:58:06 -0700 (PDT) Reply-To: Sean Christopherson Date: Thu, 30 Oct 2025 11:58:01 -0700 In-Reply-To: <20251030185802.3375059-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20251030185802.3375059-1-seanjc@google.com> X-Mailer: git-send-email 2.51.1.930.gacf6e81ea2-goog Message-ID: <20251030185802.3375059-2-seanjc@google.com> Subject: [PATCH 1/2] KVM: x86: Unload "FPU" state on INIT if and only if its currently in-use From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alexander Potapenko Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Replace the hack added by commit f958bd2314d1 ("KVM: x86: Fix potential put_fpu() w/o load_fpu() on MPX platform") with a more robust approach of unloading+reloading guest FPU state based on whether or not the vCPU's FPU is currently in-use, i.e. currently loaded. This fixes a bug on hosts that support CET but not MPX, where kvm_arch_vcpu_ioctl_get_mpstate() neglects to load FPU state (it only checks for MPX support) and leads to KVM attempting to put FPU state due to kvm_apic_accept_events() triggering INIT emulation. E.g. on a host with CET but not MPX, syzkaller+KASAN generates: Oops: general protection fault, probably for non-canonical address 0xdfff= fc0000000004: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] CPU: 211 UID: 0 PID: 20451 Comm: syz.9.26 Tainted: G S 6= .18.0-smp-DEV #7 NONE Tainted: [S]=3DCPU_OUT_OF_SPEC Hardware name: Google Izumi/izumi, BIOS 0.20250729.1-0 07/29/2025 RIP: 0010:fpu_swap_kvm_fpstate+0x3ce/0x610 ../arch/x86/kernel/fpu/core.c:= 377 RSP: 0018:ff1100410c167cc0 EFLAGS: 00010202 RAX: 0000000000000004 RBX: 0000000000000020 RCX: 00000000000001aa RDX: 00000000000001ab RSI: ffffffff817bb960 RDI: 0000000022600000 RBP: dffffc0000000000 R08: ff110040d23c8007 R09: 1fe220081a479000 R10: dffffc0000000000 R11: ffe21c081a479001 R12: ff110040d23c8d98 R13: 00000000fffdc578 R14: 0000000000000000 R15: ff110040d23c8d90 FS: 00007f86dd1876c0(0000) GS:ff11007fc969b000(0000) knlGS:0000000000000= 000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f86dd186fa8 CR3: 00000040d1dfa003 CR4: 0000000000f73ef0 PKRU: 80000000 Call Trace: kvm_vcpu_reset+0x80d/0x12c0 ../arch/x86/kvm/x86.c:11818 kvm_apic_accept_events+0x1cb/0x500 ../arch/x86/kvm/lapic.c:3489 kvm_arch_vcpu_ioctl_get_mpstate+0xd0/0x4e0 ../arch/x86/kvm/x86.c:12145 kvm_vcpu_ioctl+0x5e2/0xed0 ../virt/kvm/kvm_main.c:4539 __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:51 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x6e/0x940 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f86de71d9c9 with a very simple reproducer: r0 =3D openat$kvm(0xffffffffffffff9c, &(0x7f0000000000), 0x80b00, 0x0) r1 =3D ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0) ioctl$KVM_CREATE_IRQCHIP(r1, 0xae60) r2 =3D ioctl$KVM_CREATE_VCPU(r1, 0xae41, 0x0) ioctl$KVM_SET_IRQCHIP(r1, 0x8208ae63, ...) ioctl$KVM_GET_MP_STATE(r2, 0x8004ae98, &(0x7f00000000c0)) Alternatively, the MPX hack in GET_MP_STATE could be extended to cover CET, but from a "don't break existing functionality" perspective, that isn't any less risky than peeking at the state of in_use, and it's far less robust for a long term solution (as evidenced by this bug). Reported-by: Alexander Potapenko Fixes: 69cc3e886582 ("KVM: x86: Add XSS support for CET_KERNEL and CET_USER= ") Signed-off-by: Sean Christopherson Reviewed-by: Chao Gao Reviewed-by: Yao Yuan --- arch/x86/kvm/x86.c | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index b4b5d2d09634..d1e048d14e88 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -12137,9 +12137,6 @@ int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu= *vcpu, int r; =20 vcpu_load(vcpu); - if (kvm_mpx_supported()) - kvm_load_guest_fpu(vcpu); - kvm_vcpu_srcu_read_lock(vcpu); =20 r =3D kvm_apic_accept_events(vcpu); @@ -12156,9 +12153,6 @@ int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu= *vcpu, =20 out: kvm_vcpu_srcu_read_unlock(vcpu); - - if (kvm_mpx_supported()) - kvm_put_guest_fpu(vcpu); vcpu_put(vcpu); return r; } @@ -12788,6 +12782,7 @@ static void kvm_xstate_reset(struct kvm_vcpu *vcpu,= bool init_event) { struct fpstate *fpstate =3D vcpu->arch.guest_fpu.fpstate; u64 xfeatures_mask; + bool fpu_in_use; int i; =20 /* @@ -12811,13 +12806,23 @@ static void kvm_xstate_reset(struct kvm_vcpu *vcp= u, bool init_event) BUILD_BUG_ON(sizeof(xfeatures_mask) * BITS_PER_BYTE <=3D XFEATURE_MAX); =20 /* - * All paths that lead to INIT are required to load the guest's FPU - * state (because most paths are buried in KVM_RUN). + * Unload guest FPU state (if necessary) before zeroing XSTATE fields + * as the kernel can only modify the state when its resident in memory, + * i.e. when it's not loaded into hardware. + * + * WARN if the vCPU's desire to run, i.e. whether or not its in KVM_RUN, + * doesn't match the loaded/in-use state of the FPU, as KVM_RUN is the + * only path that can trigger INIT emulation _and_ loads FPU state, and + * KVM_RUN should _always_ load FPU state. */ - kvm_put_guest_fpu(vcpu); + WARN_ON_ONCE(vcpu->wants_to_run !=3D fpstate->in_use); + fpu_in_use =3D fpstate->in_use; + if (fpu_in_use) + kvm_put_guest_fpu(vcpu); for_each_set_bit(i, (unsigned long *)&xfeatures_mask, XFEATURE_MAX) fpstate_clear_xstate_component(fpstate, i); - kvm_load_guest_fpu(vcpu); + if (fpu_in_use) + kvm_load_guest_fpu(vcpu); } =20 void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event) --=20 2.51.1.930.gacf6e81ea2-goog From nobody Sun Feb 8 12:57:51 2026 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6721436E371 for ; Thu, 30 Oct 2025 18:58:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761850690; cv=none; b=t7Zm3KSCgguAdu/eiSm1q8zOxLOSNwfCeKBX4Gch5mJOhhkJPPxghwAvlnl9+S6ubQ4WowYelw+XnagsvnfxdRYMMfAHqhCQpAYKtRk7+SByfG6dqo1a8ykUjyiDD1+9MQSi5cYslJRpSwfHq2u6Mj+/H31zIu0V9ZbWFsxn+B4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761850690; c=relaxed/simple; bh=gBhNaafHCGkv+teWASnFAg94iaqRXR4iTaEf314TGQw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=SlrA0mcnyAycBxLnkD8c2dr7F0bFg5AeswSExs1QRSHI/bH477wgKgEhdtQ2c4Rt8NDRp1lFKYXtufPsnDNmykuy8bRqrTM8aZHStKMQZvscqsKwRBi7FGuSnnZl1m+wN6qcFTCO9eRLKva0+kvsPmSyJf9F9nXSEEg/zd1i47c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=HWs9Lyz5; arc=none smtp.client-ip=209.85.216.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="HWs9Lyz5" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-3405e02ff45so1077305a91.3 for ; Thu, 30 Oct 2025 11:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1761850688; x=1762455488; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=qjjFGFuC/i6bzqqoHJlMMUDjmHoXRQt84ZbrHXQbM7E=; b=HWs9Lyz5OCyyh3garUoE71nuAbQkfTfhXvZxE767LyOADb6ZHldXCl+V+Lka5Itmqn DkHc0lw6yju9GQUcXOPOhw9n5hvcCVaehr6+LDcrd7X4UrcKQV0Jn5tTmSGVwLtQbclf cy28DxlQ3ztPcxk7LEXKbpjGkyiXMPEG6z1rPXMEP8Ft3Z/DmJkZnazha0T4nJYl5bto lPkibCei09hYZHBXBg5jLPAPQB6LMPliJmEM8O9ODYYYCHXirSNQ3h6EPd1Xrjln6BCj 1wQgAfLQwnpGmPMJi0v8drOuvSxvN9ulSsiR0DxGkugLmCyg55RVZulHHddjlz6dKQ/7 Bq8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761850688; x=1762455488; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qjjFGFuC/i6bzqqoHJlMMUDjmHoXRQt84ZbrHXQbM7E=; b=fqGTnffKGmxvvEhVqWVvrmRxzXtb/zlR+W6AddS7cjgzGTsDx7wzTU/akAzw37EIH2 gTDLoOs7P0qIHm/YkD2wKyYW3pEbHoteMAlmZkjQf0iT6VtsY/W4BaMNn1XVh5+QH0c8 vZjDKFZkbp7KW3dF2tz5BbfLF/qrgkDQ/UNhzoH+CaK5+CeOeCr2TktD5texdA7JspEy h8W06GvxIHXcvzDZ8zo4eqizfJ5Xi8aHlk9v5XmXIh1x11l5Py2PsL3TGGb1QR+CpWGB gGAExcQZ8elTvPPTRX01k6amYsX25TqaAJu4VpUc0YozC2ccYk3hel970nt9mDpgLXyT 023Q== X-Forwarded-Encrypted: i=1; AJvYcCViUJuHuftU+w8uj1GPogRBlOF+M+vpsPca4MqCZGcTjHu78AZjaWGN2mXWS7BbUNtDBJAWFyWRqLyw1d0=@vger.kernel.org X-Gm-Message-State: AOJu0YxecXdiez5Rc5AMFRYDxb44CcHfmVdmioBf/JWH+QFkCS5/3YXU nIePRhF90p6j1XJW3rMk6fVn6XQJ8uXOl0/iztNujPDtw+Ll+z7rf7BCHqXtPd4OAAJiW1HuXKy Xn4bybg== X-Google-Smtp-Source: AGHT+IEKgvy0wUgCv5T8CNLcmWcQSEO5ENvBe1HV5y63XOGG6rep4wBvG0goTUcSpE7EICJuck+LW8gP5+Y= X-Received: from pjbqd11.prod.google.com ([2002:a17:90b:3ccb:b0:339:ae3b:2bc7]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:134e:b0:33b:dec9:d9aa with SMTP id 98e67ed59e1d1-3408308c667mr906032a91.25.1761850688619; Thu, 30 Oct 2025 11:58:08 -0700 (PDT) Reply-To: Sean Christopherson Date: Thu, 30 Oct 2025 11:58:02 -0700 In-Reply-To: <20251030185802.3375059-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20251030185802.3375059-1-seanjc@google.com> X-Mailer: git-send-email 2.51.1.930.gacf6e81ea2-goog Message-ID: <20251030185802.3375059-3-seanjc@google.com> Subject: [PATCH 2/2] KVM: x86: Harden KVM against imbalanced load/put of guest FPU state From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alexander Potapenko Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Assert, via KVM_BUG_ON(), that guest FPU state isn't/is in use when loading/putting the FPU to help detect KVM bugs without needing an assist from KASAN. If an imbalanced load/put is detected, skip the redundant load/put to avoid clobbering guest state and/or crashing the host. Note, kvm_access_xstate_msr() already provides a similar assertion. Signed-off-by: Sean Christopherson Reviewed-by: Chao Gao Reviewed-by: Yao Yuan --- arch/x86/kvm/x86.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index d1e048d14e88..67e5f735adf2 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -11807,6 +11807,9 @@ static int complete_emulated_mmio(struct kvm_vcpu *= vcpu) /* Swap (qemu) user FPU context for the guest FPU context. */ static void kvm_load_guest_fpu(struct kvm_vcpu *vcpu) { + if (KVM_BUG_ON(vcpu->arch.guest_fpu.fpstate->in_use, vcpu->kvm)) + return; + /* Exclude PKRU, it's restored separately immediately after VM-Exit. */ fpu_swap_kvm_fpstate(&vcpu->arch.guest_fpu, true); trace_kvm_fpu(1); @@ -11815,6 +11818,9 @@ static void kvm_load_guest_fpu(struct kvm_vcpu *vcp= u) /* When vcpu_run ends, restore user space FPU context. */ static void kvm_put_guest_fpu(struct kvm_vcpu *vcpu) { + if (KVM_BUG_ON(!vcpu->arch.guest_fpu.fpstate->in_use, vcpu->kvm)) + return; + fpu_swap_kvm_fpstate(&vcpu->arch.guest_fpu, false); ++vcpu->stat.fpu_reload; trace_kvm_fpu(0); --=20 2.51.1.930.gacf6e81ea2-goog