From patchwork Thu Feb 6 19:14:19 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Woodhouse X-Patchwork-Id: 13963616 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E9DAB157A5C; Thu, 6 Feb 2025 19:14:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738869265; cv=none; b=L1PhikR8Osx9P/foV2312vBJcOzFynbVQykRp63KZSEbGVFfnamAF4d7YZb58AZwQ11cJ7RvGD2JfmbDYRW44xSE/iXsYSMpqK5dP1oex+ICmZeUrWQEbrRnKEJdjXOz03KYgLcAs9+XbvaXpACjpH+2jd/H8Nnqs6dm4BRDtpo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738869265; c=relaxed/simple; bh=/rvTmKr7CewI3fbsjrwC7pXY5Kdi3H9Z6hoKIIMIXGs=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=upLy37+hNPli+mxfvpPppTqBkZVbrfioJ4IvqY54VHlFw58UD6zsjSsCInGGoOOCCfx7RHbKv56Y/+dq3zxH4mzVp/pJA4+B0HP1Tsdd7reNJhCaF+3Jcf0OjF+QkJfwtAAp9lCa4Ku6U5iWVC1eRHk/hKgDDXc9H5KOaiOWsAU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=casper.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=tFpZrykP; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=casper.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="tFpZrykP" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References: In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ll2i3T0YRlhVDLedVhyY2yx6BXxbwqLSoBAkfsC86y8=; b=tFpZrykPGR/zXNxgLII+KuCkQE HcnDxGAWTBBPZ3yIJufvvCrGUGpKdk4cwgegFODS613dEsEIsSZg0IdZT1NA4UvhiFDBxFRddHPVI dVo9c5UHHBVXvhn5o8mGBgT/mcT1IF7kMH9v4+WFqbbIiH6pykbYMWYPc3N+epp1WkjK2rqPzHaNz SW5DVMCjg3d0xGTajK0sROoz6MByw1XhxcoWr8lqwFOhOpIhm6Uq8SRVzXg1LNwWHfXPRqwkFYqtC 5+w8alN8LjVMHpcYV4AqC1D/ZZgxyFkZpBD2es4KytGpuEtn3LL03V59cJ8dtz14qijT5+RvCWq9j dPhu1/sg==; Received: from [54.239.6.187] (helo=freeip.amazon.com) by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1tg7KO-00000006TUU-34lm; Thu, 06 Feb 2025 19:14:20 +0000 Message-ID: Subject: [PATCH] KVM: x86/xen: Only write Xen hypercall page for guest writes to MSR From: David Woodhouse To: Sean Christopherson , Paolo Bonzini , Paul Durrant Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot+cdeaeec70992eca2d920@syzkaller.appspotmail.com, Joao Martins Date: Thu, 06 Feb 2025 19:14:19 +0000 In-Reply-To: <20250201011400.669483-1-seanjc@google.com> References: <20250201011400.669483-1-seanjc@google.com> User-Agent: Evolution 3.52.3-0ubuntu1 Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html From: David Woodhouse The Xen hypercall page MSR is write-only. When the guest writes an address to the MSR, the hypervisor populates the referenced page with hypercall functions. There is no reason for the host ever to write to the MSR, and it isn't even readable. Allowing host writes to trigger the hypercall page allows userspace to attack the kernel, as kvm_xen_write_hypercall_page() takes multiple locks and writes to guest memory. E.g. if userspace sets the MSR to MSR_IA32_XSS, KVM's write to MSR_IA32_XSS during vCPU creation will trigger an SRCU violation due to writing guest memory: ============================= WARNING: suspicious RCU usage 6.13.0-rc3 ----------------------------- include/linux/kvm_host.h:1046 suspicious rcu_dereference_check() usage! stack backtrace: CPU: 6 UID: 1000 PID: 1101 Comm: repro Not tainted 6.13.0-rc3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x176/0x1c0 kvm_vcpu_gfn_to_memslot+0x259/0x280 kvm_vcpu_write_guest+0x3a/0xa0 kvm_xen_write_hypercall_page+0x268/0x300 kvm_set_msr_common+0xc44/0x1940 vmx_set_msr+0x9db/0x1fc0 kvm_vcpu_reset+0x857/0xb50 kvm_arch_vcpu_create+0x37e/0x4d0 kvm_vm_ioctl+0x669/0x2100 __x64_sys_ioctl+0xc1/0xf0 do_syscall_64+0xc5/0x210 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7feda371b539 While the MSR index isn't strictly ABI, i.e. can theoretically float to any value, in practice no known VMM sets the MSR index to anything other than 0x40000000 or 0x40000200. Reported-by: syzbot+cdeaeec70992eca2d920@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/679258d4.050a0220.2eae65.000a.GAE@google.com Signed-off-by: David Woodhouse --- arch/x86/kvm/x86.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 6d4a6734b2d6..f1ecba788d0a 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3733,7 +3733,13 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info) u32 msr = msr_info->index; u64 data = msr_info->data; - if (msr && msr == vcpu->kvm->arch.xen_hvm_config.msr) + /* + * Do not allow host-initiated writes to trigger the Xen hypercall + * page setup; it could incur locking paths which are not expected + * if userspace sets the MSR in an unusual location. + */ + if (msr && msr == vcpu->kvm->arch.xen_hvm_config.msr && + !msr_info->host_initiated) return kvm_xen_write_hypercall_page(vcpu, data); switch (msr) {