CVE-2026-79610

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 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 GNTTAB_cache_flush operation, where the error path after adding a NULL check fails to drop a page reference if the page is owned by a special system domain (DOM_IO or DOM_COW).

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.