All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vincent Donnefort" <vdonnefort@google.com>
Cc: "Oliver Upton" <oupton@kernel.org>,
	"Marc Zyngier" <maz@kernel.org>,
	kvmarm@lists.linux.dev
Subject: Re: [PATCH v3 02/17] KVM: arm64: Add pkvm_remove_mappings
Date: Mon, 20 Jul 2026 17:27:07 +0000	[thread overview]
Message-ID: <20260720172707.BA6521F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720171513.1415357-3-vdonnefort@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Bounds checking `WARN_ON(from > to)` is evaluated after pointer page-alignment, silently masking inverted address ranges and unmapping unintended memory.
--

--- Patch [2]: [PATCH v3 02/17] KVM: arm64: Add pkvm_remove_mappings ---
commit baa2f13b846b3ed54bd502767e4372648ba03b42
Author: Vincent Donnefort <vdonnefort@google.com>

KVM: arm64: Add pkvm_remove_mappings

This commit adds pkvm_remove_mappings() as a counterpart to
pkvm_create_mappings(). It allows previously mapped ranges to be removed,
which will be used by the upcoming pKVM heap allocator.

[ ... ]

> diff --git a/arch/arm64/kvm/hyp/nvhe/mm.c b/arch/arm64/kvm/hyp/nvhe/mm.c
> index 8b8c9d3dc82ad..5cd2f1fe51e4c 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mm.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mm.c
> @@ -157,6 +157,19 @@ int pkvm_create_mappings(void *from, void *to, enum kvm_pgtable_prot prot)
>  	return ret;
>  }
>  
> +void pkvm_remove_mappings(void *from, void *to)
> +{
> +	u64 size;
> +
> +	to = PTR_ALIGN(to, PAGE_SIZE);
> +	from = PTR_ALIGN_DOWN(from, PAGE_SIZE);
> +	size = (u64)to - (u64)from;
> +	WARN_ON(from > to);
[Severity: Medium]
Does checking from > to after page-alignment mask inverted bounds?

If a caller provides inverted address bounds that are close enough (e.g.,
from = 0x1050, to = 0x1040), the page-alignment operations will transform
them into a valid range (from = 0x1000, to = 0x2000).

The WARN_ON(from > to) check would then evaluate to false, bypassing the
warning and silently unmapping unintended hypervisor memory.

Could the WARN_ON(from > to) check be moved before the pointers are
modified by PTR_ALIGN and PTR_ALIGN_DOWN?

> +
> +	guard(hyp_spinlock)(&pkvm_pgd_lock);
> +	WARN_ON(kvm_pgtable_hyp_unmap(&pkvm_pgtable, (u64)from, size) != size);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720171513.1415357-1-vdonnefort@google.com?part=2

  reply	other threads:[~2026-07-20 17:27 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20 17:14 [PATCH v3 00/17] KVM: arm64: Introduce pKVM hypervisor heap allocator Vincent Donnefort
2026-07-20 17:14 ` [PATCH v3 01/17] KVM: arm64: Add pkvm_private_va_range_pa Vincent Donnefort
2026-07-20 17:25   ` sashiko-bot
2026-07-20 17:14 ` [PATCH v3 02/17] KVM: arm64: Add pkvm_remove_mappings Vincent Donnefort
2026-07-20 17:27   ` sashiko-bot [this message]
2026-07-20 17:14 ` [PATCH v3 03/17] KVM: arm64: Add pkvm_map_private_va_range Vincent Donnefort
2026-07-20 17:29   ` sashiko-bot
2026-07-20 17:15 ` [PATCH v3 04/17] KVM: arm64: Add a heap allocator for the pKVM hyp Vincent Donnefort
2026-07-20 17:26   ` sashiko-bot
2026-07-20 17:15 ` [PATCH v3 05/17] KVM: arm64: Allow kvm_hyp_memcache usage outside of stage-2 Vincent Donnefort
2026-07-20 17:15 ` [PATCH v3 06/17] KVM: arm64: Add pkvm_hyp_req infrastructure Vincent Donnefort
2026-07-20 17:15 ` [PATCH v3 07/17] KVM: arm64: Add PKVM_HYP_REQ_HYP_ALLOC request Vincent Donnefort
2026-07-20 17:36   ` sashiko-bot
2026-07-20 17:15 ` [PATCH v3 08/17] KVM: arm64: Add reclaim interface for the pKVM heap alloc Vincent Donnefort
2026-07-20 17:32   ` sashiko-bot
2026-07-20 17:15 ` [PATCH v3 09/17] KVM: arm64: Add selftests for the pKVM heap allocator Vincent Donnefort
2026-07-20 17:31   ` sashiko-bot
2026-07-20 17:15 ` [PATCH v3 10/17] KVM: arm64: Add a shrinker for pKVM Vincent Donnefort
2026-07-20 17:15 ` [PATCH v3 11/17] KVM: arm64: Filter out non-kernel addresses in kern_hyp_va Vincent Donnefort
2026-07-20 17:28   ` sashiko-bot
2026-07-20 17:15 ` [PATCH v3 12/17] KVM: arm64: Move hyp_vm refcount into the structure Vincent Donnefort
2026-07-20 17:15 ` [PATCH v3 13/17] KVM: arm64: Alloc pkvm_hyp_vm using pKVM heap allocator Vincent Donnefort
2026-07-20 17:44   ` sashiko-bot
2026-07-20 17:15 ` [PATCH v3 14/17] KVM: arm64: Alloc pkvm_hyp_vcpu " Vincent Donnefort
2026-07-20 17:41   ` sashiko-bot
2026-07-20 17:15 ` [PATCH v3 15/17] KVM: arm64: Reject hyp trace descriptors with fewer CPUs than hyp_nr_cpus Vincent Donnefort
2026-07-20 17:15 ` [PATCH v3 16/17] KVM: arm64: Reject hyp trace descriptors with fewer than 3 pages Vincent Donnefort
2026-07-20 17:15 ` [PATCH v3 17/17] KVM: arm64: Alloc simple_buffer_page using pKVM hyp allocator Vincent Donnefort
2026-07-20 17:47   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260720172707.BA6521F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vdonnefort@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.