[PATCH v1 0/2] KVM: arm64: Fixes for hyp_trace

[PATCH v1 0/2] KVM: arm64: Fixes for hyp_trace

[Vincent Donnefort]

Here's a couple of fixes for hyp_trace:

The first one fixes a potential 64 bits overflow in the hypervisor trace
clock.

The second may prevent tracing loading for certain buffer_size_kb
configuration. This one depends on the allocator, so I have based the
series on kvmarm/next.

Vincent Donnefort (2):
  KVM: arm64: Prevent 64-bit overflow when computing hyp clock rate
  KVM: arm64: Fix bpages backing allocation size in hyp_trace

 arch/arm64/kvm/hyp_trace.c | 16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)


base-commit: 8ed245078003cc5f61ca4c8f9920374086f2515c
-- 
2.56.0.360.g66cac248cb-goog

[PATCH v1 1/2] KVM: arm64: Prevent 64-bit overflow when computing hyp clock rate

[Vincent Donnefort]

The hypervisor clock rate is delta_cycles * NSEC_PER_SEC / delta_boot.
It is computed whenever a deviation occurs. If the delta between two
rate updates is big enough, delta_cycles * NSEC_PER_SEC will overflow.

Prevent overflow with mul_u64_u64_div_u64(). And as a bonus, simplify
the clock estimation with mul_u64_u32_shr().

Fixes: b22888917fa4 ("KVM: arm64: Sync boot clock with the nVHE/pKVM hyp")
Cc: stable@vger.kernel.org
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
---
 arch/arm64/kvm/hyp_trace.c | 12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/kvm/hyp_trace.c b/arch/arm64/kvm/hyp_trace.c
index 9241d5a325fb..26fc13c16458 100644
--- a/arch/arm64/kvm/hyp_trace.c
+++ b/arch/arm64/kvm/hyp_trace.c
@@ -60,14 +60,8 @@ static void __hyp_clock_work(struct work_struct *work)
 	if (hyp_clock->mult) {
 		u64 err, cur = delta_cycles;
 
-		if (WARN_ON_ONCE(cur >= hyp_clock->cyc_overflow64)) {
-			__uint128_t tmp = (__uint128_t)cur * hyp_clock->mult;
-
-			cur = tmp >> hyp_clock->shift;
-		} else {
-			cur *= hyp_clock->mult;
-			cur >>= hyp_clock->shift;
-		}
+		WARN_ON_ONCE(cur >= hyp_clock->cyc_overflow64);
+		cur = mul_u64_u32_shr(cur, hyp_clock->mult, hyp_clock->shift);
 		cur += hyp_clock->boot;
 
 		err = abs_diff(cur, boot);
@@ -85,7 +79,7 @@ static void __hyp_clock_work(struct work_struct *work)
 					    err / NSEC_PER_USEC);
 	}
 
-	rate = div64_u64(delta_cycles * NSEC_PER_SEC, delta_boot);
+	rate = mul_u64_u64_div_u64(delta_cycles, NSEC_PER_SEC, delta_boot);
 
 	clocks_calc_mult_shift(&hyp_clock->mult, &hyp_clock->shift,
 			       rate, NSEC_PER_SEC, CLOCK_MAX_CONVERSION_S);
-- 
2.56.0.360.g66cac248cb-goog

[PATCH v1 2/2] KVM: arm64: Fix bpages backing allocation size in hyp_trace

[Vincent Donnefort]

hyp_trace_buffer_alloc_bpages_backing() computes nr_bpages as
(PAGE_ALIGN(size) / PAGE_SIZE) + 1, whereas trace_remote_alloc_buffer()
takes into account the buffer page header.

Align the bpages backing allocation by using
__calc_nr_pages_ring_buffer_desc(). There's no need to validate
nr_bpages again, it has been before with trace_buffer_desc_size().

Fixes: 3aed038aac8d ("KVM: arm64: Add trace remote for the nVHE/pKVM hyp")
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
---
 arch/arm64/kvm/hyp_trace.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/hyp_trace.c b/arch/arm64/kvm/hyp_trace.c
index 26fc13c16458..b9404496f977 100644
--- a/arch/arm64/kvm/hyp_trace.c
+++ b/arch/arm64/kvm/hyp_trace.c
@@ -146,8 +146,8 @@ static void __unshare_page(unsigned long va)
 
 static int hyp_trace_buffer_alloc_bpages_backing(struct hyp_trace_buffer *trace_buffer, size_t size)
 {
+	unsigned long nr_bpages;
 	size_t backing_size;
-	int nr_bpages;
 	void *start;
 	int ret;
 
@@ -157,7 +157,7 @@ static int hyp_trace_buffer_alloc_bpages_backing(struct hyp_trace_buffer *trace_
 		return 0;
 	}
 
-	nr_bpages = (PAGE_ALIGN(size) / PAGE_SIZE) + 1;
+	nr_bpages = __calc_nr_pages_ring_buffer_desc(size);
 	backing_size = PAGE_ALIGN(sizeof(struct simple_buffer_page) * nr_bpages *
 				  num_possible_cpus());
 
-- 
2.56.0.360.g66cac248cb-goog

Re: [PATCH v1 2/2] KVM: arm64: Fix bpages backing allocation size in hyp_trace

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] tracing: Integer overflow in trace buffer size calculation bypasses capacity check
--

commit 652836a529b433a8c0e0cb4f4308fa9b9556763d
Author: Vincent Donnefort <vdonnefort@google.com>

KVM: arm64: Fix bpages backing allocation size in hyp_trace

This commit updates the trace buffer backing allocation in hyp_trace to
calculate the required number of pages using
__calc_nr_pages_ring_buffer_desc(). This appropriately accounts for the
buffer page header and relies on trace_buffer_desc_size() for validation.

> diff --git a/arch/arm64/kvm/hyp_trace.c b/arch/arm64/kvm/hyp_trace.c
> index 26fc13c164589..b9404496f9775 100644
> --- a/arch/arm64/kvm/hyp_trace.c
> +++ b/arch/arm64/kvm/hyp_trace.c
[ ... ]
> @@ -157,7 +157,7 @@ static int hyp_trace_buffer_alloc_bpages_backing(struct hyp_trace_buffer *trace_
>  		return 0;
>  	}
>  
> -	nr_bpages = (PAGE_ALIGN(size) / PAGE_SIZE) + 1;
> +	nr_bpages = __calc_nr_pages_ring_buffer_desc(size);

[Severity: Low]
Does this calculation overflow if size is near SIZE_MAX?

Looking at __calc_nr_pages_ring_buffer_desc() in include/linux/ring_buffer.h:

static inline unsigned long __calc_nr_pages_ring_buffer_desc(size_t size)
{
        /* Takes into account the reader page */
        return max(DIV_ROUND_UP(size, PAGE_SIZE - BUF_PAGE_HDR_SIZE), 2UL) + 1;
}

If size is extremely large, the DIV_ROUND_UP macro wraps around, causing the
function to erroneously return a very small page count (e.g. 0 wrapping to 3
pages).

The commit message notes there is no need to validate nr_bpages again because
it was validated by trace_buffer_desc_size(), but could this overflow bypass
that check?

Looking at trace_buffer_desc_size() in include/linux/ring_buffer.h:

        /* Capped by ring_buffer_desc::nr_page_va */
        if (nr_pages > UINT_MAX)
                return SIZE_MAX;

Because the wrapped nr_pages is small, this capacity check would be
circumvented, bypassing the intended -E2BIG rejection. Downstream consumers
like hyp_trace_buffer_alloc_bpages_backing(), trace_remote_alloc_buffer(),
and __tracing_load() would then operate safely on this truncated page count.
This results in a silent failure where the kernel allocates a tiny functional
trace buffer instead of returning an error for the impossibly large
allocation.

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

Re: [PATCH v1 1/2] KVM: arm64: Prevent 64-bit overflow when computing hyp clock rate

[Fuad Tabba]

On Thu, 8 Oct 2026 at 11:42, 'Vincent Donnefort' via kernel-team
<kernel-team@android.com> wrote:
>
> The hypervisor clock rate is delta_cycles * NSEC_PER_SEC / delta_boot.
> It is computed whenever a deviation occurs. If the delta between two
> rate updates is big enough, delta_cycles * NSEC_PER_SEC will overflow.
>
> Prevent overflow with mul_u64_u64_div_u64(). And as a bonus, simplify
> the clock estimation with mul_u64_u32_shr().
>
> Fixes: b22888917fa4 ("KVM: arm64: Sync boot clock with the nVHE/pKVM hyp")
> Cc: stable@vger.kernel.org
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>

Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Tested-by: Fuad Tabba <fuad.tabba@linux.dev>

Cheers,
/fuad

Re: [PATCH v1 2/2] KVM: arm64: Fix bpages backing allocation size in hyp_trace

[Fuad Tabba]

On Thu, 8 Oct 2026 at 11:42, Vincent Donnefort <vdonnefort@google.com> wrote:
>
> hyp_trace_buffer_alloc_bpages_backing() computes nr_bpages as
> (PAGE_ALIGN(size) / PAGE_SIZE) + 1, whereas trace_remote_alloc_buffer()
> takes into account the buffer page header.
>
> Align the bpages backing allocation by using
> __calc_nr_pages_ring_buffer_desc(). There's no need to validate
> nr_bpages again, it has been before with trace_buffer_desc_size().
>
> Fixes: 3aed038aac8d ("KVM: arm64: Add trace remote for the nVHE/pKVM hyp")

Should this have Cc: stable too, like patch 1? The undercount is there
since 3aed038aac8d for small buffers, and 442ffa742daa6
("tracing/remotes: Account for ring buffer page header in size
calculation") makes it reachable at ordinary sizes.

Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Tested-by: Fuad Tabba <fuad.tabba@linux.dev>

Cheers,
/fuad

Re: [PATCH v1 2/2] KVM: arm64: Fix bpages backing allocation size in hyp_trace

[Vincent Donnefort]

On Thu, Oct 08, 2026 at 08:13:29PM +0100, Fuad Tabba wrote:
> On Thu, 8 Oct 2026 at 11:42, Vincent Donnefort <vdonnefort@google.com> wrote:
> >
> > hyp_trace_buffer_alloc_bpages_backing() computes nr_bpages as
> > (PAGE_ALIGN(size) / PAGE_SIZE) + 1, whereas trace_remote_alloc_buffer()
> > takes into account the buffer page header.
> >
> > Align the bpages backing allocation by using
> > __calc_nr_pages_ring_buffer_desc(). There's no need to validate
> > nr_bpages again, it has been before with trace_buffer_desc_size().
> >
> > Fixes: 3aed038aac8d ("KVM: arm64: Add trace remote for the nVHE/pKVM hyp")
> 
> Should this have Cc: stable too, like patch 1? The undercount is there
> since 3aed038aac8d for small buffers, and 442ffa742daa6
> ("tracing/remotes: Account for ring buffer page header in size
> calculation") makes it reachable at ordinary sizes.
> 
> Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
> Tested-by: Fuad Tabba <fuad.tabba@linux.dev>
> 
> Cheers,
> /fuad
> 
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
>

Yeah I wasn't sure, because __calc_nr_pages_ring_buffer_desc() was introduced
later.

But I can figure it out once the patch fails to apply and provide the
appropriate backport.

Thanks for the review.

-- 
Vincent

Re: [PATCH v1 0/2] KVM: arm64: Fixes for hyp_trace

[Marc Zyngier]

On Thu, 08 Oct 2026 11:42:10 +0100, Vincent Donnefort wrote:
> Here's a couple of fixes for hyp_trace:
> 
> The first one fixes a potential 64 bits overflow in the hypervisor trace
> clock.
> 
> The second may prevent tracing loading for certain buffer_size_kb
> configuration. This one depends on the allocator, so I have based the
> series on kvmarm/next.
> 
> [...]

Applied to next, thanks!

[1/2] KVM: arm64: Prevent 64-bit overflow when computing hyp clock rate
      commit: 6164ce3491bcc3a27a2e2e9260a286eb2df2301e
[2/2] KVM: arm64: Fix bpages backing allocation size in hyp_trace
      commit: aac4560e1287c36196fd2d78bf04d0c1c2559e3e

Cheers,

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