Commit Graph
2 Commits
Author SHA1 Message Date
Weiqi Wang e028aac940 argo: bound len before comparing offset in memcpy_to_guest_ring()
memcpy_to_guest_ring() bounds the copy against the ring size with

    if ( len + offset > XEN_ARGO_MAX_RING_SIZE )

where len and offset are unsigned int. offset is masked below
PAGE_SIZE just above, but a len close to UINT_MAX makes len + offset
wrap below XEN_ARGO_MAX_RING_SIZE and pass the check. The head_len
computation in the loop wraps the same way, so the copy length is no
longer bounded.

All current callers bound len via iov_count(), so this is not
reachable in practice.

No functional change for in-range inputs.

Signed-off-by: Weiqi Wang <weiqi.wang-2@postgrad.manchester.ac.uk>
Acked-by: Jan Beulich <jbeulich@suse.com>
2026-10-14 09:24:54 +02:00
Weiqi Wang c161c11875 xen/pdx: fix offset-compression merge of a contained range
When sorting and merging overlapping ranges in
pfn_pdx_compression_setup(), the merged range is set to end where the
second range ends.  If the second range is fully contained in the first,
this truncates the first range, and the tail of it is then neither
compressible nor translated correctly.

Keep the end of the merged range as the maximum of both ends.

On x86 the ranges come from the SRAT memory affinity entries, and
overlapping entries for the same node are tolerated with a warning by the
NUMA code.  The caller's subsequent coverage check catches the truncated
range, so the effect is that PDX compression is disabled with a "RAM
region ... not covered" message rather than memory being mistranslated.

Add a test case that fails without this change.

Found with the ESBMC bounded model checker, and confirmed by running the
failing case natively against the unmodified code.

Fixes: c5c45bcbd6 ("pdx: introduce a new compression algorithm based on region offsets")
Assisted-by: Claude Code:claude-opus-5-5 # finding the issue with ESBMC, patch creation
Signed-off-by: Weiqi Wang <weiqi.wang-2@postgrad.manchester.ac.uk>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
2026-10-12 09:41:55 +02:00