From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) (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 131E631ED80 for ; Wed, 29 Jul 2026 17:06:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785344793; cv=none; b=O9iQayct5cxMnMz7hKzJt7akPeRInT8biyrnINQc+Oc3N0wrPjMiU0VLMG3cPqyCy+FwHXFWq9M+mic12rfuOq1LrO44hU85MBrL0uWEr7c9CjaX+qqWFSCvwjDQKNl48zPMumeZ0HEXlVxWj2EmCildaUik8cZDcF25XAPhNX8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785344793; c=relaxed/simple; bh=tsiOlAUa96Yb2zXENGGsMr86rnfZCA9ALJ7FgQ6u+oU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=ZegyGqQ/jSE4NFR7w/SIyU4TTzKRStOAKNzustrLKO7PecBKJA2ywFpkGq77a+/1M/8/DM+xkwnZLI0URyN8MQv+m94dA2atUWDfq3hRtiqDvG3+WCo0IGFQzmDGrlez/+f0KHTnywy7FSzQLNZGGurpegCnKBUlM/hlEonBtqM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=I3KzD3y6; arc=none smtp.client-ip=209.85.218.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="I3KzD3y6" Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-c197f968b3cso186768466b.2 for ; Wed, 29 Jul 2026 10:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1785344790; x=1785949590; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=JUjgOR7a0LIRa7JTwKXaksAfk4KfPx7m8MrD3Mnq65c=; b=I3KzD3y61JpwzMdgNytyKg2gr5ETKNNPk9/kamMPvTkwxTkJwgJREJprzFIV+MHsop 0gg/PwEuTte4k1pp3b9KlYexbjY3WQv3u/J7cADDYJZfKEU+E4or0Q5mHpuH3MHqwLo6 KSCqiU2RIl90BnFWXDOJlP8xV2o6uatXiTRNI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785344790; x=1785949590; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=JUjgOR7a0LIRa7JTwKXaksAfk4KfPx7m8MrD3Mnq65c=; b=lBlc4gOXrLDcbgRf6aR+jJur2ltMBGwzesYYNl7/au/THYIc3ygnlnCyDmWZb8Skhs PlZa2B66KfiI2uuofIRBgJA9aN7GbkE+wfiK0rp+UBk+TWB6aGxmLzXEzkg7Z2hAuqTR nt2KfcOxMHsZs+tYkJsm84bVdLJfrM+Sa8GKBD0h9u5wrC7Eo+JLIVhCQQMznriDpn7G CCz71fWF9CdsoN/HaNYsvNK5/MT+X5s4hdj1aXVKy4GCh/d5BiP7kPOdE30A9ltH6Bg+ GdijfZhaQePaNuW0xJDEO5S+yelEa9O2kIw3yaP7Weqqju9LffsrhGkngwWqHJFLI6zf RdLQ== X-Forwarded-Encrypted: i=1; AHgh+Rr8rmlXLPLcaMzrofCCRVvTq0Yo0b12PLTn9i1LuKsTEOupD5CbqHbEQppMpdHGaR+pJhfw+XjobGQlC1k=@vger.kernel.org X-Gm-Message-State: AOJu0YwroypedFGDH2VD4oBgGpBJg/emUg3+mcM1hRQj5CdoVT4uAtXE x5ULsPS3SJij9imO8sYoc79K75Cerf7ao90Em3zBkcH2WCtmQXFXcD2tAoMpCoBSrQ== X-Gm-Gg: AR+sD10JotWSX2luhzyzOvyrkDQp1HFws6S8saBD7FERWOnSW7r0UfwWAjgSgQ8Vupx wRYiy1p4kbtXgR4uvAiitkyZzhx4gVkJOK44LPXx7OUFykv7NXssUXaUJhZrkI/gnIg1buiYN8N 4hZieh1u9cfbnCjeikeiQTiazE79CjI3d2x+/dMwgpthRuT0QSFR1eCSfJM4+QF1Sg2WM3IC747 A9+qTLN1wEXv6Xp6rosouyfZGCwT4iJ9tLch0S386x7SNAMeocLpp/HsObASSRC3HY+CV00uy+S uunpLvmSZp+vqRbIFwmxeqBRox7jivetHgOoJEh6DqyPKZ3V7eoIO8wwXp6wysl35EvzDJk9JZp 1zzJPTV4ulFuwxHL8i5w1/b9KkcDqk3VeiIYD9k7e05F4CkVgHIwHMaEgBMmwQ4Z/oVfSF+1+EA jY78L3hPL4XZZJ/eaqX7kQECuc2ZowuxnMtJoXiU2pPCHcdo28nX6hP7SFaD516DwT60KcMRMz1 eJwporBPgQJK4hBOK0Dx4U1Y1fAT48kxlcT7dF0FjmTmv8uzbU546M= X-Received: by 2002:a17:907:9487:b0:c12:6584:c1 with SMTP id a640c23a62f3a-c1f7221f3aemr422167466b.40.1785344790234; Wed, 29 Jul 2026 10:06:30 -0700 (PDT) Received: from dmaluka.c.googlers.com.com (110.121.148.146.bc.googleusercontent.com. [146.148.121.110]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c1f83c686a8sm142753566b.4.2026.07.29.10.06.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jul 2026 10:06:29 -0700 (PDT) From: Dmytro Maluka To: Sean Christopherson Cc: Paolo Bonzini , Dave Hansen , Chao Gao , Kai Huang , Naveen N Rao , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Vineeth Pillai , Chuanxiao Dong , Aashish Sharma , Grzegorz Jaszczyk , Dmytro Maluka Subject: [PATCH v2 0/2] KVM: VMX: Fix IPIv use-after-free + improve checking duplicate vcpu_id Date: Wed, 29 Jul 2026 17:06:19 +0000 Message-ID: <20260729170621.308809-1-dmaluka@chromium.org> X-Mailer: git-send-email 2.55.0.508.g3f0d502094-goog Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit vCPU creation in kvm_vm_ioctl_create_vcpu() may fail after kvm_arch_vcpu_create() -> vmx_vcpu_create() already succeeded. In such case kvm_vm_ioctl_create_vcpu() destroys the newly created vCPU in the failure path. However, that leaves a side effect: the IPIv pid_table entry remains configured with this vCPU's pi_desc address. As a result, when another vCPU sends an IPI to the APIC ID of this failed-to-create vCPU, it will cause HW to write to this (freed!) pi_desc memory. The straightforward way to fix this is to clear the pid_table entry in vmx_vcpu_free(), which is what patch 2 in this series does. But that requires addressing a related meta-issue first: if userspace tries to create a vCPU with the same vcpu_id as an existing one, kvm_vm_ioctl_create_vcpu() checks for that and fails with -EEXIST only after it already created the vCPU via kvm_arch_vcpu_create(). As a result, clearing the pid_table entry in the vmx_vcpu_free() in the failure path would clear the pid_table entry for that already existing good vCPU, i.e. effectively disable IPIv for that vCPU. For this reason, the v1 patch [1] addressed the IPIv issue by postponing the pid_table entry setup until kvm_arch_vcpu_postcreate() when we are sure that the vCPU creation succeeded, instead of clearing it when destroying the vCPU. However, as pointed out by Sean [2], insufficient validation of vcpu_id before calling kvm_arch_vcpu_create() is a potential source of a whole class of similar issues, so it's better to fix this meta-issue once and for all. Another concern about the v1 approach is that initializing vCPU state in vcpu_postcreate, after the vCPU is already reachable, is generally tricky. So patch 1 in this series moves checking for duplicated vcpu_id in kvm_vm_ioctl_create_vcpu() earlier, before creating the vCPU. To do that without races, it introduces the kvm->vcpu_ids bitmap (see patch 1 description for the details). It is a slightly adjusted version of Sean's bitmap patch from [2]. P.S. Note that the same IPIv use-after-free issue exists on SVM as well, as pointed out by sashiko and confirmed by Naveen [3]. This remains to be fixed. (Supposedly it is as trivial to fix as for VMX, but I'll leave that to someone who's familiar with that and has AMD hardware.) [1] https://lore.kernel.org/kvm/20260716160801.3155582-1-dmaluka@chromium.org/ [2] https://lore.kernel.org/kvm/al6eg7C-2sDBEAFD@google.com/ [3] https://lore.kernel.org/kvm/al4rNqpBYy8FGKPw@blrnaveerao1/ Dmytro Maluka (2): KVM: Check for duplicate vcpu_id as early as possible KVM: VMX: Fix stale PID-pointer table entry left after vCPU free arch/x86/kvm/vmx/vmx.c | 3 +++ include/linux/kvm_host.h | 1 + virt/kvm/kvm_main.c | 9 ++++++++- 3 files changed, 12 insertions(+), 1 deletion(-) -- 2.55.0.508.g3f0d502094-goog