Уязвимости xen

gnttab: cache-flush handling may cause page reference leak

With its original introduction, GNTTAB_cache_flush was made available uniformly. XSA-232 (CVE-2017-14318) then covered an omitted NULL pointer check, yet the addition of that check failed to adjust the subsequent error path. That error path fails to drop a page reference in case the specified page is owned by a special system domain (DOM_IO and DOM_COW are system domains which can have memory pages assigned to them.)

Arm: multiple issues with GNTTABOP_cache_flush

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] 1) XSA-437 (CVE-2023-34321) addressed issues with overflows in calculations involved in guests flushing caches through GNTTABOP_cache_flush. Unfortunately the fix there introduced a calculation which may underflow, resulting in a loop which would - at least on 64-bit Arm - take excessively long, and which would likely eventually crash the hypervisor. This is CVE-2026-102699. 2) GNTTABOP_cache_flush may be issued on memory mapped from another domain using the grant table interface. However t

Arm: multiple issues with GNTTABOP_cache_flush

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] 1) XSA-437 (CVE-2023-34321) addressed issues with overflows in calculations involved in guests flushing caches through GNTTABOP_cache_flush. Unfortunately the fix there introduced a calculation which may underflow, resulting in a loop which would - at least on 64-bit Arm - take excessively long, and which would likely eventually crash the hypervisor. This is CVE-2026-102699. 2) GNTTABOP_cache_flush may be issued on memory mapped from another domain using the grant table interface. However t

VMX: VMentry failure with branch tracing and blocked states

For XSA-308 logic was introduced, as VMX VMEntry checks do not like the exact combination of state which occurs when #DB in intercepted, Single Stepping is active, and blocked by STI/MovSS is active, despite this being a legitimate state to be in. The resulting VMEntry failure is fatal to the guest. Sadly there is another special sub-case of the above, with branch tracing enabled. In that case the prior adjustment would still cause a VMentry failure, as before fatal to the guest.

grant-table: double version change race

XSA-501 was about issues with v1 -> v2 and v2 -> v1 changes racing certain other grant table operations. Sadly a v2 -> v1 -> v2 change has yet another effect which wasn't accounted for: During the first change, status pages would be freed. During the second change they would be allocated again. Hence across the full pair of change the addresses of the status pages may change, rendering stale previously calculated pointers into the status array.

x86: XPTI may break on huge-memory systems

XPTI (Xen Page Table Isolation) was introduced to mitigate Meltdown (CVE-2017-5754, one aspect of XSA-254). This involves copying 64-bit PV guest page table entries from guest-chosen root page tables to the Xen- chosen one which is in actual use by hardware. To read the guest root page table, the directmap is used. PV guests, however, have a directmap which may not cover all memory; in particular this is the case if any memory extends beyond the 5 TiB (CONFIG_BIGMEM=y: 3.5 TiB) address boundary.

x86/AMD: ineffectual Zenbleed workaround

The workaround for XSA-433 (Zenbleed, CVE-2023-20593) was later re-worked to better integrate with other manipulations of the same MSR. In this rework an inverted conditional was introduced, resulting in the workaround to not be applied when needed and vice versa. For more details, see: http://xenbits.xen.org/xsa/advisory-433.html

Xenstore: Guests can crash xenstored during Live Update

During Xenstore live update 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.

DEBIAN-CVE-2026-102701

DEBIAN-CVE-2026-102701

Unconditionally do TLB flushing ahead of page scrubbing

x86 PV guests can free memory pages while still keeping a stale TLB entry pointing to them. A TLB flush is only issued by Xen (if needed) when the page is re-used. Since it's possible for the page to be scrubbed ahead of the TLB flush, there's a window where a PV guest can modify an already scrubbed page.

x86: improper handling of HVM emulation return codes

A guest with a PCI device assigned that has at least a BAR on the IO port space can trigger a BUG() in Xen.

x86: DMs may cause mem leak by IRQ binding

When guests are terminated, various pieces of cleanup need carrying out. The cleaning up of PCI devices which were assigned to guests, and the associated removal of tracking structures for IRQs used by the devices occurs relatively early in the process. Unfortunately after that point the guest about to be terminated could cause its device model (DM) to re-establish such tracking structures, by having it bind one or more IRQs anew. While some of those tracking structures would still be cleaned up later on, at least one would not be.

UBUNTU-CVE-2026-79604

oxenstored: Unbounded accumulation of watches: Oxenstored maintains two datastructures about watches; one global trie, and one hashtable tracked per domain. When a xenbus reconnect is requested, watches are not cleared out of the global trie. A guest can cause unbounded memory usage in oxenstored. This can lead to a system-wide DoS. All version of Xen from 4.6 onwards are vulnerable. Only systems using the Ocaml Xenstored implementation are vulnerable. Systems using the C Xenstored implementation are not vulnerable.

PoD: Don't try to reclaim special pages

A guest started with Populated on Demand enabled (PoD) can attempt to reclaim pages which aren't regular guest RAM. This can cause corruption of memory management state in Xen.

• Обновитесь до 4.17.7-0+deb12u1

correct buffer checks for DM_OP hypercalls

Parts of the DM_OP handling code assumes the caller has provided the required number of buffers for the given operation without any checking being done. As a result, certain operations might access stack rubble as structures are possibly uninitialized.

• Обновитесь до 4.17.7-0+deb12u1

evtchn: Race between FIFO expand and reset

The EVTCHNOP_expand_array hypercall checks for whether FIFO event channels are enabled, but without holding the correct lock. It can race with EVTCHNOP_reset, resulting in dereferencing a NULL pointer.

• Обновитесь до 4.17.7-0+deb12u1

Viridian STIMER division by zero

The logic to handle periodic Viridian STIMERs performs a division with an unchecked user-controlled divisor value, that can be set to zero to cause a #DE fault.

• Обновитесь до 4.17.7-0+deb12u1

x86: Out-of-bounds read in vRTC emulation

Accesses to the CMOS memory contents are done using an indirect IO port pair. Therefore Xen needs to cache the guest chosen index, and one of the usages of the index didn't take the necessary locking to avoid concurrent changes. As a result, a guest could change the index after it being checked, causing a subsequent out-of-bound read access to the contents of an array.

• Обновитесь до 4.17.7-0+deb12u1

vNUMA domain cleanup may race other operations

Accessing the vNUMA configuration data of a guest is still possible when domain destruction has already started. The cleaning up of that configuration information is not synchronized with its retrieval by a device model controlling the guest.

• Обновитесь до 4.17.7-0+deb12u1

grant-table: version change racing with other operations

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] With the introduction of Grant Table v2 came the requirement to be able to switch between versions. Switching from v1 to v2 reduces the number of valid grant references, as a bigger shared entry structure is then needed while the shared table doesn't change size. Switching from v2 back to v1 the status frames, which are separate in v2, go away. Code holding, but intermediately dropping and then re-acquiring the grant table lock, sometimes wrongly assumes that said properties wouldn't change across the window in

• Обновитесь до 4.17.7-0+deb12u1