From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 B0DE13D9524; Thu, 2 Jul 2026 19:59:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783022377; cv=none; b=rWLR9+23nOaULMXoevIXjqB06h62s2kapb6FuWPEqByreWoSbm1LS74hojnnEoMotVq7NlPp4in/AkoHDqVmt6xDNezfckGZYcSQiUcEX6KGWYtxIt7j2mWZczB+9m0o2QW25RAqFd95ksTE512lbvWDUXAuOFujbM6qOHPgNTs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783022377; c=relaxed/simple; bh=PQcuAUV0siySJRetknBRAzzc65l0mdrRHJJ/wa1PZKw=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=C/1Cu65TANaKQjS/OC8G3DBC1EWjlnUV9STgMfSNPsl9MbLXbRORBF37bVVQ9Of0+CHeXzeJkSHuRKROdbDSTkzV3YcQ7lt4J44N3g0C7A8oG0kV+kZXYNOwHNJ0P+Fp/PLhLXF7M+ev2eLmksAZQotZgu+a1U/7xEgy17E8DTM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=L0CPMjyo; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="L0CPMjyo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 248771F000E9; Thu, 2 Jul 2026 19:59:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783022375; bh=2H84jcPhig+PVKKxSH9Gzi9Rut0c6k2u8jyizPMaWwM=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=L0CPMjyo+YOTKfofr/4WZONO4h6qCCNT+2EkNSIr4Aa6djNQSTC6WUIZ/7EhCT3c2 NGBLlLOC+LEZbavA5whqsbw13+TiKYN4SCKOJCAD+2lHwQ2cbvy3cH4uUxdLCRYDup R8HUtJg7a5fXXOi46Nu5++9QKkx+/sCsob9tW4NdOZyzQTfB2hT34fG1tNuF4sXtXz Ck5nPCg2TfgpuGct4Bqg9bEWbZrGjG9z5ftRlFs1PSvBz+OKNY/FCmQ7GIW7j5hvPd LYlKy6fJvOGM6REjtLsSX3Fvz671DKuIGbbfgrorKbHJPatWz6/lqfjHg4fGgsChRi HkOyLIx1qMNdA== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wfNZM-00000000tw2-3Ywm; Thu, 02 Jul 2026 19:59:32 +0000 Date: Thu, 02 Jul 2026 21:01:21 +0100 Message-ID: <87qzll6u0e.wl-maz@kernel.org> From: Marc Zyngier To: sashiko-reviews@lists.linux.dev Cc: kvmarm@lists.linux.dev, "Oliver Upton" , kvm@vger.kernel.org Subject: Re: [PATCH 27/28] KVM: arm64: Expose FEAT_NV3 to guests In-Reply-To: <20260702163903.852691F00A3E@smtp.kernel.org> References: <20260702160248.1377250-1-maz@kernel.org> <20260702160248.1377250-28-maz@kernel.org> <20260702163903.852691F00A3E@smtp.kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: sashiko-reviews@lists.linux.dev, kvmarm@lists.linux.dev, oupton@kernel.org, kvm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 02 Jul 2026 17:39:02 +0100, sashiko-bot@kernel.org wrote: > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: > > Pre-existing issues: > - [Critical] A maliciously or incorrectly configured vCPU can trigger a host NULL pointer dereference by requesting an ID register configuration where NV_frac = 0, causing KVM to skip VNCR TLB allocation while still trapping VNCR accesses. > -- > > commit ca23c995d48d1c5c8370918930aa81e2eeb147ab > Author: Marc Zyngier > > KVM: arm64: Expose FEAT_NV3 to guests > > Further enable FEAT_NV3 by making it visible to NV guests. > > > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c > > index c9bf04944f9cb..64c8fb82fadf6 100644 > > --- a/arch/arm64/kvm/nested.c > > +++ b/arch/arm64/kvm/nested.c > > @@ -1728,7 +1728,7 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val) > > * You get EITHER > > * > > * - FEAT_VHE without FEAT_E2H0 > > - * - FEAT_NV limited to FEAT_NV2(p1) > > + * - FEAT_NV limited to FEAT_NV2(p1)/NV3 > > * - HCR_EL2.NV1 being RES0 > > * > > * OR > > @@ -1740,7 +1740,9 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val) > > if (test_bit(KVM_ARM_VCPU_HAS_EL2_E2H0, kvm->arch.vcpu_features)) { > > val = 0; > > [Severity: Critical] > This is a pre-existing issue, but could this cause a host NULL pointer > dereference? > > If userspace configures a vCPU with KVM_ARM_VCPU_HAS_EL2_E2H0, this branch > forces the entire ID_AA64MMFR4_EL1 register to 0. This includes the NV_frac > field. Alternatively, userspace could explicitly set ID_AA64MMFR4_EL1.NV_frac > to 0 via KVM's ID register UAPI. > > When KVM initializes the nested vCPU, it calls kvm_vcpu_allocate_vncr_tlb() > which checks NV_frac: > > arch/arm64/kvm/nested.c:kvm_vcpu_allocate_vncr_tlb() { > if (!kvm_has_feat(vcpu->kvm, ID_AA64MMFR4_EL1, NV_frac, NV2_ONLY)) > return 0; > ... > } > > Because NV_frac is 0, the check evaluates to false and the function silently > returns success without allocating vcpu->arch.vncr_tlb. > > Since vcpu_has_nv() only checks for KVM_ARM_VCPU_HAS_EL2, the vCPU is allowed > to run. If the guest then accesses a VNCR-trapped register or sets HCR_EL2.NV, Beeeeeeeep!!!! It looked so good until then... "VNCR-trapped register" means nothing, as the whole point of VNCR is to *not* trap, but to write to memory instead. So OK, the page isn't there, and a write to a register targeting VNCR_EL2 could generate a fault. But if ID_AA64MMFR4_EL1.NV_frac==0, then HCR_EL2.NV is RES0: NEEDS_FEAT(HCR_EL2_AT | /* Ignore the original FEAT_NV */ HCR_EL2_NV2 | HCR_EL2_NV, feat_nv2), and feat_nv2 reads: static bool feat_nv2(struct kvm *kvm) { return ((kvm_has_feat(kvm, ID_AA64MMFR4_EL1, NV_frac, NV2_ONLY) && kvm_has_feat_enum(kvm, ID_AA64MMFR2_EL1, NV, NI)) || kvm_has_feat(kvm, ID_AA64MMFR2_EL1, NV, NV2)); } which will return false in the proposed case, making HCR_EL2.NV firmly RES0. Yes, there's a reason why I spent so much time on this crap. Since HCR_EL2.NV is RES0, we never ERET to an L2 running at EL2, and therefore there is never a case where we fault on a guest provided VNCR page. > the host exit handler calls kvm_translate_vncr() or kvm_map_l1_vncr(). Both > functions unconditionally dereference the unallocated vncr_tlb: > > arch/arm64/kvm/nested.c:kvm_translate_vncr() { > struct vncr_tlb *vt = vcpu->arch.vncr_tlb; > ... > vt->valid = false; > ... > } > > Will this lead to a kernel panic when unprivileged userspace configures a > vCPU this way? Don't think so. M. -- Jazz isn't dead. It just smells funny.