The VCPUOP_register_runstate_memory_area hypercall tries to update the
newly registered area, even when NULL is being registered. If the guest
happens to have memory mapped at 0 in the address space, this write will
succeed.
Ever since it's introduction in Xen 3.0, NULL is the initial state of the
pointer, and guards the update of the runstate area in context_switch().
NULL has also been accepted as an input to the hypercall.
It is unclear whether de-registration of the area was considered at the
time, but the behaviour of the hypercall has always supported this.
De-registering using NULL is a common pattern for other hypercalls, so
formally make this the case for VCPUOP_register_runstate_memory_area by
skipping the update if the area has been de-registered.
Fixes: 705ea2b54c ("New VCPUOP_register_runstate_memory_area hypercall.")
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
XENFEAT_pae_pgdir_above_4gb is only used by 32bit PV guests, hence limit
its setting in XENVER_get_features to the is_pv_domain() guarded section,
with the rest of the PV specific features. Add an additional build time
guard to short-circuit the setting of XENFEAT_pae_pgdir_above_4gb if the
hypervisor has no PV 32bit support.
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The current logic on x86 will mark all domain owned pages as needing a TLB
flush before being re-used. However such TLB flushing is only strictly
needed when the pages might have been mapped by a PV domain, as those can
keep a reference to the page in the TLB after it has been freed.
Limit the flushing to builds with PV domain support, as tracking whether a
page might have been mapped by a PV domain is not trivial (and possibly not
worth the extra logic).
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Adjust some types: int -> bool, int -> unsigned int. Also fix a couple of
typos plus trailing white space.
No functional change intended.
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The current way in which idle TLB flush and TLB flushing when allocating a
page are done allows for the scrubbing to be done ahead of the TLB flush.
A PV domain can still have a TLB entry for the page after scrubbing, and
hence it may be able to modify it. Such unintended page accessing allows
domains to possibly exchange information even when `xsm=silo scrub-domheap`
are in effect.
Remove the MEMF_no_tlbflush memory allocation flag, and reorder the
flushing so it's always done ahead of the scrubbing in
alloc_{,color_}heap_pages(). The sole user of MEMF_no_tlbflush is
populate_physmap(), and given the constrains above it's no longer safe
to defer the flush, hence the flag removal and the folding of the flush in
the allocator function itself.
This is XSA-511 / CVE-2026-79603.
Fixes: 24f1a58d19 ("mm: option to _always_ scrub freed domheap pages")
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
hvm_io_intercept() can return X86EMUL_RETRY, and as such it needs to be
handled in the switch in hvmemul_do_io() to avoid triggering the BUG() from
the default case.
Reset the vCPU state to no in-flight IOREQ and return X86EMUL_RETRY so that
the access is retried.
This is XSA-510 / CVE-2026-79602.
Reported-by: Jiqian Chen <Jiqian.Chen@amd.com>
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
It's possible for domains to generate unaligned PCI config space accesses
when using ECAM, and hence vPCI should support those at least for the
hardware domain. Such unaligned accesses to the PCI config space have been
reported to come from ACPI logic.
Relax the checking in vpci_access_allowed() to allow such accesses for the
hardware domain, and fix the handling in pci_conf_{read,write}{16,32}() to
fulfill them using MMCFG.
MMCFG regions are identity exposed to the hardware domain, and hence such
unaligned accesses can only come as a result of the host having MMCFG in the
first place, as otherwise MMCFG won't be exposed to the hardware domain
either.
Note that vpci_ecam_{read,write}() already refuse accesses that cross a
device boundary unconditionally.
Reported-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Roger Pau Monne