CVE-2026-102700

The vulnerability in Xen concerns logic introduced for XSA-308, which does not handle a certain combination of VMX VMEntry state when #DB is intercepted, single stepping is active, and blocked by STI/MovSS. With branch tracing enabled, the prior adjustment still causes a VMEntry failure, fatal to the guest.

The vulnerability in Xen concerns issues with grant table operations, where v2 -> v1 -> v2 changes can lead to changes in the addresses of status pages. Previously calculated pointers into the status array may become stale, potentially leading to incorrect behavior.

The vulnerability in Xen concerns the XPTI (Xen Page Table Isolation) mechanism, which copies PV guest page table entries from guest-chosen root page tables to the Xen-chosen one. PV guests may have a directmap that does not cover all memory, especially when memory extends beyond the 5 TiB (or 3.5 TiB with CONFIG_BIGMEM=y) address boundary.

The vulnerability in Xen concerns the workaround for XSA-433 (Zenbleed), which was reworked but introduced an inverted conditional, causing the workaround to not be applied when needed and vice versa.

The vulnerability in Xenstore concerns live update, where the state record for a Xenstore watch with specified watch depth is written with two bytes missing. This results in an inconsistent state when reading the state back in the new Xenstore, causing a crash of Xenstore or wrong Xenstore data.

The vulnerability in Xen concerns the GNTTABOP_cache_flush operation, which may be issued on memory mapped from another domain using the grant table interface. There was no restriction to disallow the use of invalidate-without-clean against read-only grant mappings, which may corrupt the granted memory.

The vulnerability in Xen concerns the GNTTABOP_cache_flush operation, where the fix for XSA-437 introduced a calculation that may underflow, resulting in a loop that would take excessively long, potentially crashing the hypervisor, especially on 64-bit Arm.

When switching from Grant Table v2 to v1 in Xen, code holding the grant table lock but temporarily dropping and re-acquiring it wrongly assumes that table properties won't change during the window without the lock. This leads to issues with status frames that disappear when switching from v2 to v1.

When switching from Grant Table v1 to v2 in Xen, code holding the grant table lock but temporarily dropping and re-acquiring it wrongly assumes that table properties won't change during the window without the lock. This leads to a reduction in the number of valid grant references.

A guest with Populated on Demand (PoD) enabled may attempt to reclaim pages that are not regular guest RAM. This can cause corruption of memory management state in Xen.