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.

In the Linux kernel, the following vulnerability has been resolved:

xen/pvcalls: bound backend response reqid before indexing rsp[]

pvcallsfronteventhandler() takes reqid directly from the backend-supplied ring response and uses it to index the fixed-size bedata->rsp[] array for a memcpy() and a store, with no range check. A malicious or buggy backend can set reqid past PVCALLSNRRSPPERRING and drive an out-of-bounds write past the bedata allocation.

reqid was also declared int while the wire field rsp->reqid is u32, so a range check on the signed value alone is insufficient: a backend reqid of 0xffffffff becomes -1, passes a >= PVCALLSNRRSPPERRING test and indexes bedata->rsp[-1]. Declare reqid as u32 so a single bound covers both ends.

A backend that sends an out-of-range reqid has violated the wire protocol, so rather than silently dropping the response, log once and stop trusting the backend: set bedata->disabled. The event handler then ignores further responses, and the request paths that wait for a response return -EIO instead of blocking forever. This mirrors the fatal-error handling xen-netback uses (xenviffataltxerr()).

The pvcalls frontend currently trusts its backend, so this is not a classic-Xen security issue, but it matters for hardening PV frontends against malicious backends (confidential and disaggregated deployments).

Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.

Last updated 25 April 2025

The adjustments made for XSA-379 as well as those subsequently becoming XSA-387 still left a race window, when a HVM or PVH guest does a grant table version change from v2 to v1 in parallel with mapping the status page(s) via XENMEMaddtophysmap. Some of the status pages may then be freed while mappings of them would still be inserted into the guest's secondary (P2M) page tables.

Any guest can cause xenstored to crash by issuing a XSRESETWATCHES command within a transaction due to an assert() triggering.

In case xenstored was built with NDEBUG #defined nothing bad will happen, as assert() is doing nothing in this case. Note that the default is not to define NDEBUG for xenstored builds even in release builds of Xen.

A flaw was found in hw. Incomplete cleanup of microarchitectural fill buffers on some Intel® Processors may allow an authenticated user to enable information disclosure via local access.

A flaw was found in hw. Incomplete cleanup in specific special register write operations for some Intel® Processors may allow an authenticated user to enable information disclosure via local access.

A flaw was found in hw. Incomplete cleanup of multi-core shared buffers for some Intel® Processors may allow an authenticated user to enable information disclosure via local access.

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.

With its original introduction, GNTTABcacheflush 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 (DOMIO and DOMCOW are system domains which can have memory pages assigned to them.)

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.

[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 GNTTABOPcacheflush. 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) GNTTABOPcacheflush may be issued on memory mapped from another domain using the grant table interface. However there was no restriction to disallow the use of invalidate-without-clean against read-only grant mappings, which may corrupt the granted memory.

This is CVE-2026-102702.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-102701 / XSA-521 version 2

tapdisk: Out-of-bounds access in tapctlconnectxenblkif()

UPDATES IN VERSION 2 ====================

Public release.

ISSUE DESCRIPTION =================

Tapdisk is a userspace xen-blkback implementation used by the XAPI toolstack.

During connection, multi-page rings may be negotiated between the frontend and backend. Tapdisk had no boundary check on the size requested by the frontend, and assumed it did not exceed 8.

IMPACT ======

A buggy or malicious guest can cause a stack overflow in tapdisk, potentially leading to code execution. Tapdisk normally runs as root.

VULNERABLE SYSTEMS ==================

All versions of tapdisk are vulnerable.

MITIGATION ==========

There are no mitigations.

CREDITS =======

This issue was discovered by Claude Opus and diagnosed as a security issue by Teddy Astie of Vates.

RESOLUTION ==========

Applying the attached patch resolves this issue.

xsa521.patch blktap master

$ sha256sum xsa521 72ece150e9d0836f217f3382c8dc76cd51bffbe4b7610c00f219b90e5600cbc5 xsa521.patch $

DEPLOYMENT DURING EMBARGO =========================

Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators.

But: Distribution of updated software is prohibited (except to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmrOIvgMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZgdgIAKXTyop/90HNxeBpRVbYP2vrPCm2YBMzoc3YtxdM 0wWdbFvUptHWnzypCWuUGJWq8ZFf4lInnkJrj0sJ9te+OSQDqcfwTMEQuDWzBM08 lQ27H0kcum3rble2V2CFCK4uOoLYwOYX/bA5vCeGiiPQcUU3m++6IoAMaRY7G2V7 RTNJmNCtbGiC7l3ExUX9KxnFCSaX9gL99YkygybBecSsjJhdlGZj7pzvJtomv1sC fVSAFmXkivLGKX8TXQdj/48xmdqNSIQgYbdSdyZgGjmy7bxIgxB576FHwlN/fzf7 ZzpeEO8yZTFWeCJCKZavvjsq/7u2vxUtpoL3c81vSKWCOLc= =w1aW -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-79607 / XSA-514 version 2

Xenstore: Guests can crash xenstored during Live Update

UPDATES IN VERSION 2 ====================

Public release.

ISSUE DESCRIPTION =================

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.

IMPACT ======

An unprivileged guest can cause the Xenstore service to crash or to get corrupted during a live update of Xenstore, causing a DoS of the host regarding further domain administration actions.

VULNERABLE SYSTEMS ==================

Only systems running Xen 4.22 are vulnerable. Systems running Xen 4.21 or older are not vulnerable.

Only systems running C xenstore either as daemon or as stubdom are vulnerable. Systems running oxenstored are not vulnerable.

MITIGATION ==========

Not doing a live update of Xenstore avoids the vulnerability.

Switching to oxenstored avoids the vulnerability.

CREDITS =======

This issue was discovered by Andrii Sultanov of Vates.

RESOLUTION ==========

Applying the attached patch resolves this issue.

Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.

xsa514.patch xen-unstable - Xen 4.22.x

$ sha256sum xsa514 8774d9b45db75851560db70a9be06d5e379311bd3042d9049bc29456e141ae7d xsa514.patch $

DEPLOYMENT DURING EMBARGO =========================

Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. Not doing a live update of Xenstore as a mitigation is permitted. Switching to oxenstored is not permitted, as this is a guest visible configuration change.

But: Distribution of updated software is prohibited (except to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmrOIa8MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZB5YH+wf2251Z1DOOtQcCB1LV9vsunIaEGd5l7pHdIZ3a 3j9A6r/KGc+RtSgDB9TWCMgjKLbBfwivOxBHHhxjhejsfnUKUJNryJFLn86plFdu VRrdk5pHmypNgb9mCf3KQ8BQputnuAu36QuIlw3F5z5XAanmyurT1QJKV0RXLrQF J3ROkGAGYp6gHhPDBFwCi/dWE/I1PRfvi53oyPPflj2kAh3DPwycpPQV0JZommjC ljh1uvyPMnwr76nnh5e4LmismWa9Gks/p3BQuF01w3Prj/vR4wRxLEMCPjhK6xV6 PLcKgrt+DGn/xwj7fEdaAVlXyh4YcxQlmUWHzaNm94Knq+8= =BuOZ -----END PGP SIGNATURE-----

A new cache speculation vulnerability known as Branch History Injection (BHI) or Spectre-BHB was found. Spectre-BHB is similar to Spectre v2, except that malicious code uses the shared branch history (stored in the CPU Branch History Buffer, or BHB) to influence mispredicted branches within the victim's own hardware context. Once that occurs, speculation caused by mispredicted branches can be used to cause cache allocation, which can then be used to infer information that should not be accessible.

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

When grant-copy operations are processed, the respective grant may or may not already be in use by another operation (a mapping or another copy). For all copy operations the referenced guest frame is looked up. When another operation is already active for the grant (the grant is "pinned"), what is being supplied back to actually carry out permission checks and copy operation may not be consistent: The permission check may be carried out on a page different from the one involved in the copy.

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]

The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver derives several lengths directly from attacker-controlled on-disk fields without validating them:

The directory loop itself assumes a good record length. This is CVE-2026-42494.

The calculation of the System Use area may underflow. This is CVE-2026-42495.

The Rock Ridge extension loop assumes a good (inner) record length. This is CVE-2026-62423.

The Rock Ridge NM record processing assumes a good entry length. This is CVE-2026-62424.

The Rock Ridge CE record processing assumes a good size and offset. This is CVE-2026-62425.

Xen guests need to use different processor instructions to make explicit calls into the Xen hypervisor depending on guest type and/or CPU vendor. In order to hide those differences, the hypervisor can fill a hypercall page with the needed instruction sequences, allowing the guest operating system to call into the hypercall page instead of having to choose the correct instructions.

The hypercall page contains whole functions, which are written by the hypervisor and executed by the guest. With the lack of an interface between the guest OS and the hypervisor specifying how a potential modification of those functions should look like, the Xen hypervisor has no knowledge how any potential mitigation should look like or which hardening features should be put into place.

This results in potential vulnerabilities if the guest OS is using any speculative mitigation that performs a compiler transform on "ret" instructions in order to work (e.g. the Linux kernel rethunk or safe-ret mitigations).

Furthermore, the hypercall page has no provision for Control-flow Integrity schemes (e.g. kCFI/CET-IBT/FineIBT), and will simply malfunction in such configurations.

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] XAPI can configure different users with different roles, using Role Based Access Control. For more details, see:

https://docs.xenserver.com/en-us/xencenter/current-release/rbac-overview.html#rbac-roles

The pool-admin role is fully privileged. Notably, users with this role can also SSH into the host as root.

The other administrator roles are pool-operator, vm-power-admin and vm-admin, each of which are authorised to configure and manage various aspects of the system.

Some settings are inadequately restricted, and can be set by a lower privilege of administrator than expected.

CVE-2026-23559: A vm-admin can set VBD.otherconfig:backend-local and turn arbitrary files in dom0 into VDIs (virtual disks) and give said disks to a VM they control. This is an arbitrary read and/or modify of files in dom0.

CVE-2026-23560: A vm-admin can set VM.other-config:issystemdomain and mark a VM as a system domain. System domains are ignored and left running during certain other host/pool operations, and may be hidden from view in tooling.

CVE-2026-23561: A vm-admin can set VM.otherconfig:storagedriverdomain and mark a VM as the storage domain for a particular host storage connection (PBD). Shutting down the VM can cause the PBD to be erroneously marked as unplugged when it is not.

CVE-2026-23562: Configuration of PCI passthrough is normally restricted to the pool-admin role. However one API was missing this check, allowing a vm-admin access to unintended host hardware.

CVE-2026-42486: A vm-admin can set the VM.platform:hvmserial parameter, which should be restricted to the pool-admin role, as it can allow arbitrary dom0 file write.

A transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries.

x86: unintended memory sharing between guests On Intel systems that support the "virtualize APIC accesses" feature, a guest can read and write the global shared xAPIC page by moving the local APIC out of xAPIC mode. Access to this shared page bypasses the expected isolation that should exist between two guests.

Xenstore: Guests can cause Xenstore to not free temporary memory When working on a request of a guest, xenstored might need to allocate quite large amounts of memory temporarily. This memory is freed only after the request has been finished completely. A request is regarded to be finished only after the guest has read the response message of the request from the ring page. Thus a guest not reading the response can cause xenstored to not free the temporary memory. This can result in memory shortages causing Denial of Service (DoS) of xenstored.

Xenstore: Guests can get access to Xenstore nodes of deleted domains Access rights of Xenstore nodes are per domid. When a domain is gone, there might be Xenstore nodes left with access rights containing the domid of the removed domain. This is normally no problem, as those access right entries will be corrected when such a node is written later. There is a small time window when a new domain is created, where the access rights of a past domain with the same domid as the new one will be regarded to be still valid, leading to the new domain being able to get access to a node which was meant to be accessible by the removed domain. For this to happen another domain needs to write the node before the newly created domain is being introduced to Xenstore by dom0.

Xenstore: Cooperating guests can create arbitrary numbers of nodes T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Since the fix of XSA-322 any Xenstore node owned by a removed domain will be modified to be owned by Dom0. This will allow two malicious guests working together to create an arbitrary number of Xenstore nodes. This is possible by domain A letting domain B write into domain A's local Xenstore tree. Domain B can then create many nodes and reboot. The nodes created by domain B will now be owned by Dom0. By repeating this process over and over again an arbitrary number of nodes can be created, as Dom0's number of nodes isn't limited by Xenstore quota.

Xenstore: Guests can crash xenstored via exhausting the stack Xenstored is using recursion for some Xenstore operations (e.g. for deleting a sub-tree of Xenstore nodes). With sufficiently deep nesting levels this can result in stack exhaustion on xenstored, leading to a crash of xenstored.

Xenstore: Cooperating guests can create arbitrary numbers of nodes T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Since the fix of XSA-322 any Xenstore node owned by a removed domain will be modified to be owned by Dom0. This will allow two malicious guests working together to create an arbitrary number of Xenstore nodes. This is possible by domain A letting domain B write into domain A's local Xenstore tree. Domain B can then create many nodes and reboot. The nodes created by domain B will now be owned by Dom0. By repeating this process over and over again an arbitrary number of nodes can be created, as Dom0's number of nodes isn't limited by Xenstore quota.

Xenstore: Guests can create arbitrary number of nodes via transactions T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] In case a node has been created in a transaction and it is later deleted in the same transaction, the transaction will be terminated with an error. As this error is encountered only when handling the deleted node at transaction finalization, the transaction will have been performed partially and without updating the accounting information. This will enable a malicious guest to create arbitrary number of nodes.