[PATCH] KVM: arm64: Reject the stage-2 MMU pointer hypercalls under pKVM

[PATCH] KVM: arm64: Reject the stage-2 MMU pointer hypercalls under pKVM

[Fuad Tabba]

The five hypercalls that take a struct kvm_s2_mmu pointer remain
callable after pKVM finalises, and each dereferences the host pointer
in __load_stage2(). Under pKVM none of them has a valid caller: the
host walks no guest stage-2, its TLB flushes go through the handle-based
__pkvm_tlb_flush_vmid, and kvm_arch_vcpu_load() skips the CPU context
flush.

Reject all five when protected mode is enabled.

Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260914130152.F0D5F1F000FF@smtp.kernel.org/
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---

Notes:
    No in-tree host path reaches these, so no Fixes: tag.

 arch/arm64/kvm/hyp/nvhe/hyp-main.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 9a3b92e626adb..4b0d00e55e2ea 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -557,6 +557,9 @@ static void handle___kvm_tlb_flush_vmid_ipa(struct kvm_cpu_context *host_ctxt)
 	DECLARE_REG(phys_addr_t, ipa, host_ctxt, 2);
 	DECLARE_REG(int, level, host_ctxt, 3);
 
+	if (unlikely(is_protected_kvm_enabled()))
+		return;
+
 	__kvm_tlb_flush_vmid_ipa(kern_hyp_va(mmu), ipa, level);
 }
 
@@ -566,6 +569,9 @@ static void handle___kvm_tlb_flush_vmid_ipa_nsh(struct kvm_cpu_context *host_ctx
 	DECLARE_REG(phys_addr_t, ipa, host_ctxt, 2);
 	DECLARE_REG(int, level, host_ctxt, 3);
 
+	if (unlikely(is_protected_kvm_enabled()))
+		return;
+
 	__kvm_tlb_flush_vmid_ipa_nsh(kern_hyp_va(mmu), ipa, level);
 }
 
@@ -576,6 +582,9 @@ handle___kvm_tlb_flush_vmid_range(struct kvm_cpu_context *host_ctxt)
 	DECLARE_REG(phys_addr_t, start, host_ctxt, 2);
 	DECLARE_REG(unsigned long, pages, host_ctxt, 3);
 
+	if (unlikely(is_protected_kvm_enabled()))
+		return;
+
 	__kvm_tlb_flush_vmid_range(kern_hyp_va(mmu), start, pages);
 }
 
@@ -583,6 +592,9 @@ static void handle___kvm_tlb_flush_vmid(struct kvm_cpu_context *host_ctxt)
 {
 	DECLARE_REG(struct kvm_s2_mmu *, mmu, host_ctxt, 1);
 
+	if (unlikely(is_protected_kvm_enabled()))
+		return;
+
 	__kvm_tlb_flush_vmid(kern_hyp_va(mmu));
 }
 
@@ -602,6 +614,9 @@ static void handle___kvm_flush_cpu_context(struct kvm_cpu_context *host_ctxt)
 {
 	DECLARE_REG(struct kvm_s2_mmu *, mmu, host_ctxt, 1);
 
+	if (unlikely(is_protected_kvm_enabled()))
+		return;
+
 	__kvm_flush_cpu_context(kern_hyp_va(mmu));
 }
 

base-commit: fd73f4a6659897191fa0d40695fe370925dd3780
-- 
2.39.5

Re: [PATCH] KVM: arm64: Reject the stage-2 MMU pointer hypercalls under pKVM

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Hypercall handlers `handle___kvm_adjust_pc`, `handle___vgic_v5_save_apr`, and `handle___vgic_v5_restore_vmcr_apr` dereference host-provided pointers via `kern_hyp_va()` without validation, allowing a malicious host to corrupt EL2-private memory under pKVM.
--

commit 6af3790e411879ef8c99b26ae2afdc619730e489
Author: Fuad Tabba <fuad.tabba@linux.dev>

KVM: arm64: Reject the stage-2 MMU pointer hypercalls under pKVM

This patch updates five stage-2 MMU pointer hypercalls to reject execution when
pKVM is enabled. It adds an is_protected_kvm_enabled() check to prevent
invalid execution paths.

Link: https://lore.kernel.org/all/20260914130152.F0D5F1F000FF@smtp.kernel.org/

> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index 9a3b92e626adb..4b0d00e55e2ea 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c

[ ... ]

arch/arm64/kvm/hyp/nvhe/hyp-main.c:handle___kvm_adjust_pc() {
	DECLARE_REG(struct kvm_vcpu *, vcpu, host_ctxt, 1);

	__kvm_adjust_pc(kern_hyp_va(vcpu));
}

[Severity: Critical]
This is a pre-existing issue, but does this code allow a malicious host to
corrupt EL2-private memory?

The unvalidated host pointer vcpu is passed directly to __kvm_adjust_pc
which mutates it. An untrusted host could invoke the
__KVM_HOST_SMCCC_FUNC___kvm_adjust_pc hypercall with a crafted pointer (e.g.,
an EL2 private-memory pointer which is idempotent under kern_hyp_va()). The
handler handle___kvm_adjust_pc directly passes this unvalidated pointer to the
underlying function, which dereferences it. This could allow the host to
overwrite arbitrary EL2 memory or leak its contents into system registers.

arch/arm64/kvm/hyp/nvhe/hyp-main.c:handle___vgic_v5_save_apr() {
	DECLARE_REG(struct vgic_v5_cpu_if *, cpu_if, host_ctxt, 1);

	__vgic_v5_save_apr(kern_hyp_va(cpu_if));
}

arch/arm64/kvm/hyp/nvhe/hyp-main.c:handle___vgic_v5_restore_vmcr_apr() {
	DECLARE_REG(struct vgic_v5_cpu_if *, cpu_if, host_ctxt, 1);

	__vgic_v5_restore_vmcr_apr(kern_hyp_va(cpu_if));
}

[Severity: Critical]
This is a pre-existing issue, but can these handlers corrupt EL2 memory under
pKVM?

Similar to the above, the unvalidated host pointer cpu_if is dereferenced and
written to by __vgic_v5_save_apr and __vgic_v5_restore_vmcr_apr. An
untrusted host could invoke the corresponding hypercalls with a crafted pointer,
allowing a malicious host to corrupt EL2-private memory.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914174521.832575-1-fuad.tabba@linux.dev?part=1

Re: [PATCH] KVM: arm64: Reject the stage-2 MMU pointer hypercalls under pKVM

[Fuad Tabba]

On Mon, 14 Sept 2026 at 18:58, <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [Critical] Hypercall handlers `handle___kvm_adjust_pc`, `handle___vgic_v5_save_apr`, and `handle___vgic_v5_restore_vmcr_apr` dereference host-provided pointers via `kern_hyp_va()` without validation, allowing a malicious host to corrupt EL2-private memory under pKVM.

All three are correct, and all three are already being fixed.
handle___kvm_adjust_pc in [1], the GICv5 handlers in [2], and the rest
in this patch.

Cheers,
/fuad

[1] https://lore.kernel.org/all/20260914065136.3418404-1-fuad.tabba@linux.dev/
[2] https://lore.kernel.org/all/20260817103228.1203140-1-fuad.tabba@linux.dev/


> --
>
> commit 6af3790e411879ef8c99b26ae2afdc619730e489
> Author: Fuad Tabba <fuad.tabba@linux.dev>
>
> KVM: arm64: Reject the stage-2 MMU pointer hypercalls under pKVM
>
> This patch updates five stage-2 MMU pointer hypercalls to reject execution when
> pKVM is enabled. It adds an is_protected_kvm_enabled() check to prevent
> invalid execution paths.
>
> Link: https://lore.kernel.org/all/20260914130152.F0D5F1F000FF@smtp.kernel.org/
>
> > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > index 9a3b92e626adb..4b0d00e55e2ea 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
>
> [ ... ]
>
> arch/arm64/kvm/hyp/nvhe/hyp-main.c:handle___kvm_adjust_pc() {
>         DECLARE_REG(struct kvm_vcpu *, vcpu, host_ctxt, 1);
>
>         __kvm_adjust_pc(kern_hyp_va(vcpu));
> }
>
> [Severity: Critical]
> This is a pre-existing issue, but does this code allow a malicious host to
> corrupt EL2-private memory?
>
> The unvalidated host pointer vcpu is passed directly to __kvm_adjust_pc
> which mutates it. An untrusted host could invoke the
> __KVM_HOST_SMCCC_FUNC___kvm_adjust_pc hypercall with a crafted pointer (e.g.,
> an EL2 private-memory pointer which is idempotent under kern_hyp_va()). The
> handler handle___kvm_adjust_pc directly passes this unvalidated pointer to the
> underlying function, which dereferences it. This could allow the host to
> overwrite arbitrary EL2 memory or leak its contents into system registers.
>
> arch/arm64/kvm/hyp/nvhe/hyp-main.c:handle___vgic_v5_save_apr() {
>         DECLARE_REG(struct vgic_v5_cpu_if *, cpu_if, host_ctxt, 1);
>
>         __vgic_v5_save_apr(kern_hyp_va(cpu_if));
> }
>
> arch/arm64/kvm/hyp/nvhe/hyp-main.c:handle___vgic_v5_restore_vmcr_apr() {
>         DECLARE_REG(struct vgic_v5_cpu_if *, cpu_if, host_ctxt, 1);
>
>         __vgic_v5_restore_vmcr_apr(kern_hyp_va(cpu_if));
> }
>
> [Severity: Critical]
> This is a pre-existing issue, but can these handlers corrupt EL2 memory under
> pKVM?
>
> Similar to the above, the unvalidated host pointer cpu_if is dereferenced and
> written to by __vgic_v5_save_apr and __vgic_v5_restore_vmcr_apr. An
> untrusted host could invoke the corresponding hypercalls with a crafted pointer,
> allowing a malicious host to corrupt EL2-private memory.
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260914174521.832575-1-fuad.tabba@linux.dev?part=1

Re: [PATCH] KVM: arm64: Reject the stage-2 MMU pointer hypercalls under pKVM

[Marc Zyngier]

On Mon, 14 Sep 2026 19:11:59 +0100,
Fuad Tabba <fuad.tabba@linux.dev> wrote:
> 
> On Mon, 14 Sept 2026 at 18:58, <sashiko-bot@kernel.org> wrote:
> >
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> >
> > Pre-existing issues:
> > - [Critical] Hypercall handlers `handle___kvm_adjust_pc`, `handle___vgic_v5_save_apr`, and `handle___vgic_v5_restore_vmcr_apr` dereference host-provided pointers via `kern_hyp_va()` without validation, allowing a malicious host to corrupt EL2-private memory under pKVM.
> 
> All three are correct, and all three are already being fixed.
> handle___kvm_adjust_pc in [1], the GICv5 handlers in [2], and the rest
> in this patch.

But that's part of the problem. I see a bunch of random patches
addressing similar problems, sent without any logic.

You really need to group related patches together, because the only
possible outcome of your current way of posting things is that I'll
drop something on the floor.

	M.

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

Re: [PATCH] KVM: arm64: Reject the stage-2 MMU pointer hypercalls under pKVM

[Marc Zyngier]

On Mon, 14 Sep 2026 18:45:21 +0100,
Fuad Tabba <fuad.tabba@linux.dev> wrote:
> 
> The five hypercalls that take a struct kvm_s2_mmu pointer remain
> callable after pKVM finalises, and each dereferences the host pointer
> in __load_stage2(). Under pKVM none of them has a valid caller: the
> host walks no guest stage-2, its TLB flushes go through the handle-based
> __pkvm_tlb_flush_vmid, and kvm_arch_vcpu_load() skips the CPU context
> flush.
> 
> Reject all five when protected mode is enabled.
> 
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/all/20260914130152.F0D5F1F000FF@smtp.kernel.org/
> Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
> ---
> 
> Notes:
>     No in-tree host path reaches these, so no Fixes: tag.
> 
>  arch/arm64/kvm/hyp/nvhe/hyp-main.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index 9a3b92e626adb..4b0d00e55e2ea 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -557,6 +557,9 @@ static void handle___kvm_tlb_flush_vmid_ipa(struct kvm_cpu_context *host_ctxt)
>  	DECLARE_REG(phys_addr_t, ipa, host_ctxt, 2);
>  	DECLARE_REG(int, level, host_ctxt, 3);
>  
> +	if (unlikely(is_protected_kvm_enabled()))
> +		return;
> +
>  	__kvm_tlb_flush_vmid_ipa(kern_hyp_va(mmu), ipa, level);
>  }
>  
> @@ -566,6 +569,9 @@ static void handle___kvm_tlb_flush_vmid_ipa_nsh(struct kvm_cpu_context *host_ctx
>  	DECLARE_REG(phys_addr_t, ipa, host_ctxt, 2);
>  	DECLARE_REG(int, level, host_ctxt, 3);
>  
> +	if (unlikely(is_protected_kvm_enabled()))
> +		return;
> +
>  	__kvm_tlb_flush_vmid_ipa_nsh(kern_hyp_va(mmu), ipa, level);
>  }
>  
> @@ -576,6 +582,9 @@ handle___kvm_tlb_flush_vmid_range(struct kvm_cpu_context *host_ctxt)
>  	DECLARE_REG(phys_addr_t, start, host_ctxt, 2);
>  	DECLARE_REG(unsigned long, pages, host_ctxt, 3);
>  
> +	if (unlikely(is_protected_kvm_enabled()))
> +		return;
> +
>  	__kvm_tlb_flush_vmid_range(kern_hyp_va(mmu), start, pages);
>  }
>  
> @@ -583,6 +592,9 @@ static void handle___kvm_tlb_flush_vmid(struct kvm_cpu_context *host_ctxt)
>  {
>  	DECLARE_REG(struct kvm_s2_mmu *, mmu, host_ctxt, 1);
>  
> +	if (unlikely(is_protected_kvm_enabled()))
> +		return;
> +
>  	__kvm_tlb_flush_vmid(kern_hyp_va(mmu));
>  }
>  
> @@ -602,6 +614,9 @@ static void handle___kvm_flush_cpu_context(struct kvm_cpu_context *host_ctxt)
>  {
>  	DECLARE_REG(struct kvm_s2_mmu *, mmu, host_ctxt, 1);
>  
> +	if (unlikely(is_protected_kvm_enabled()))
> +		return;
> +
>  	__kvm_flush_cpu_context(kern_hyp_va(mmu));
>  }
>  

Anf why not __kvm_flush_vm_context()? It doesn't take a S2 MMU
pointer, but it is still logically wrong to let this being called.

And the whole sprinkling of guards like this is just horrible. We
already have a filtering mechanism, just make use of it:

diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index bffdeb36da1d2..51bf30b671fe4 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -62,6 +62,11 @@ enum __kvm_host_smccc_func {
 	__KVM_HOST_SMCCC_FUNC___kvm_enable_ssbs,
 	__KVM_HOST_SMCCC_FUNC___vgic_v3_init_lrs,
 	__KVM_HOST_SMCCC_FUNC___vgic_v3_get_gic_config,
+	__KVM_HOST_SMCCC_FUNC___kvm_flush_vm_context,
+	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_ipa,
+	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_ipa_nsh,
+	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid,
+	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_range,
 
 	MARKER(__KVM_HOST_SMCCC_FUNC_MIN_PKVM),
 
@@ -70,11 +75,6 @@ enum __kvm_host_smccc_func {
 	/* Hypercalls that are always available and common to [nh]VHE/pKVM. */
 	__KVM_HOST_SMCCC_FUNC___kvm_adjust_pc,
 	__KVM_HOST_SMCCC_FUNC___kvm_vcpu_run,
-	__KVM_HOST_SMCCC_FUNC___kvm_flush_vm_context,
-	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_ipa,
-	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_ipa_nsh,
-	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid,
-	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_range,
 	__KVM_HOST_SMCCC_FUNC___kvm_flush_cpu_context,
 	__KVM_HOST_SMCCC_FUNC___kvm_timer_set_cntvoff,
 	__KVM_HOST_SMCCC_FUNC___tracing_load,


Thanks,

	M.

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

Re: [PATCH] KVM: arm64: Reject the stage-2 MMU pointer hypercalls under pKVM

[Fuad Tabba]

Hi Marc,

On Tue, 15 Sept 2026 at 10:24, Marc Zyngier <maz@kernel.org> wrote:
[...]
> > @@ -602,6 +614,9 @@ static void handle___kvm_flush_cpu_context(struct kvm_cpu_context *host_ctxt)
> >  {
> >       DECLARE_REG(struct kvm_s2_mmu *, mmu, host_ctxt, 1);
> >
> > +     if (unlikely(is_protected_kvm_enabled()))
> > +             return;
> > +
> >       __kvm_flush_cpu_context(kern_hyp_va(mmu));
> >  }
> >
>
> Anf why not __kvm_flush_vm_context()? It doesn't take a S2 MMU
> pointer, but it is still logically wrong to let this being called.

I'll respin these, as you suggest, and consolidate them. I'll mention
in the cover letter which series/patches the new one supersedes.

Sorry for the noise,
/fuad

>
> And the whole sprinkling of guards like this is just horrible. We
> already have a filtering mechanism, just make use of it:
>
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index bffdeb36da1d2..51bf30b671fe4 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -62,6 +62,11 @@ enum __kvm_host_smccc_func {
>         __KVM_HOST_SMCCC_FUNC___kvm_enable_ssbs,
>         __KVM_HOST_SMCCC_FUNC___vgic_v3_init_lrs,
>         __KVM_HOST_SMCCC_FUNC___vgic_v3_get_gic_config,
> +       __KVM_HOST_SMCCC_FUNC___kvm_flush_vm_context,
> +       __KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_ipa,
> +       __KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_ipa_nsh,
> +       __KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid,
> +       __KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_range,
>
>         MARKER(__KVM_HOST_SMCCC_FUNC_MIN_PKVM),
>
> @@ -70,11 +75,6 @@ enum __kvm_host_smccc_func {
>         /* Hypercalls that are always available and common to [nh]VHE/pKVM. */
>         __KVM_HOST_SMCCC_FUNC___kvm_adjust_pc,
>         __KVM_HOST_SMCCC_FUNC___kvm_vcpu_run,
> -       __KVM_HOST_SMCCC_FUNC___kvm_flush_vm_context,
> -       __KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_ipa,
> -       __KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_ipa_nsh,
> -       __KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid,
> -       __KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_range,
>         __KVM_HOST_SMCCC_FUNC___kvm_flush_cpu_context,
>         __KVM_HOST_SMCCC_FUNC___kvm_timer_set_cntvoff,
>         __KVM_HOST_SMCCC_FUNC___tracing_load,
>
>
> Thanks,
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.