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).

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.

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

Xen Security Advisory CVE-2025-54518 / XSA-490

x86: CPU Opcode Cache corruption

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

AMD have disclosed a potential vulnerability in certain CPUs which can cause instructions to execute at a higher privilege.

For more information, see: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7052.html

IMPACT ======

Code of any privilege could escalate to a higher privilege, including userspace to kernel, and guest to host.

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

Systems running all versions of Xen are affected.

Only AMD Fam17h CPUs (Zen2 microarchitecture) are believed to be vulnerable. Other AMD CPUs and CPUs from other manufacturers are not known to be affected.

MITIGATION ==========

There are no mitigations.

RESOLUTION ==========

Applying the appropriate attached patch resolves this issue.

For Xen 4.17, patch 1 is a backport of a change which only went back as far as 4.18 under normal bugfix rules, but which is tightly texturally coupled with the XSA-940 fix. It is possible to rework patch 2 to avoid patch 1, but a number of Xen-focused downstreams already have patch 1 backported, and those without patch 1 really ought to take it. So, while this is slightly abnormal for an XSA, it is believed to be in the best interest of everyone with a 4.17 based Xen.

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.

xsa490.patch xen-unstable xsa490-4.21.patch Xen 4.21.x - Xen 4.18.x xsa490-4.17-?.patch Xen 4.17.x

$ sha256sum xsa490 7c256d3384bf640d171ae2f18930c193a72bbdd92ebeb8942e58634dd7b27439 xsa490.patch 4d64d95937630f2147bb69d0d0ff24fc7d97efd48e376d882265662f93886ec7 xsa490-4.17-1.patch 6c717a5bd914088463c74b89893672388848a2222165478aed63b6c2a4151e28 xsa490-4.17-2.patch 1e397550a542bc0957bf93a6e6f01ffcdfe8f005697a505c62ec6120a72d3f90 xsa490-4.21.patch $ -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmoDTuQMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZn38H/2xujQ3YDEsE2U8RiH/6M1yVxnATlCEqEPBxIcVX h6W4QMzlFw/IXZBi6twduuzMME2uX6eKWCbE9riw2v4lybgNYMxV20oW86LhjLwr uL1NHJ3Fop1IuRy+po20jmT9sPfpieHU9zGmFvgd/k91gSZ1b/5G8k36MtgODL0j 4Svsdo3LYSvULQn5EymjO/t57ZZIDBWj5Od7aBbPuGkQKtW6+/UCE0JnrzOtP+Di 0Y5bBSUhwrMh0h32AV/w2nwvFQN/EeyakfjDWQc1ST6wHzFMLSo2kaY40TZ6C+T8 RnN646ouPizmiSDu2G/dMrLJ5kc3PFqQvN3JRI4dyf075yg= =Dclq -----END PGP SIGNATURE-----

[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.

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.

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

Xen Security Advisory CVE-2026-23556 / XSA-483 version 2

oxenstored keeps quota related use counts across domain destruction

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

Public release.

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

When oxenstored is tearing a domain down, the node data is cleaned up but the usage counts are leaked.

When the domain ID is eventually reused, the new domain can create fewer nodes before beeing deemed to be over quota.

IMPACT ======

Over an extended period of time, new domains will be able to create fewer and fewer nodes in xenstored, until they are eventually unable to operate at all.

A buggy or malicious domain can speed this process up by deliberately hitting it's quota, and then rebooting.

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

All versions of Xen containing the XSA-419 fixes are vulnerable.

Only systems configured to use oxenstored (Ocaml xenstored) are vulnerable. Systems configured to xenstored (C xenstored) are not vulnerable.

MITIGATION ==========

Performing a xenstore live update mitigates the issue.

CREDITS =======

This issue was discovered by Andrii Sultanov of Vates.

RESOLUTION ==========

Applying the appropriate 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.

xsa483.patch xen-unstable - Xen 4.18.x xsa483-4.17.patch Xen 4.17.x xsa483-xapi.patch XAPI oxenstored

$ sha256sum xsa483 4be3acc57dcd5e2719cab165729879757a1915c33b848a37623dd4a5f1157746 xsa483.patch 389b0411d855894adff6f640dcbd3358adc6d4cb9ddeedbcb9cb2c345af67d51 xsa483-4.17.patch ec191a1e158eddd22bfbd764f26f6b6a0b75b9fe0a223dc66da1c4a16ef73122 xsa483-xapi.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/4UyVfoK9kFAmnwoPIMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZM8EH/iXC6hLQHAVLeRCfUEZ1ncM7029KPyRxLIOlthCS cAyMNjyVSckGMRgKvYWCpl/fN1v/2yv3olIIR9wtncaq8Q+iMkwOsw1P46fmsh3J 40pK6PnaP1/kRrua1ZANlUc8YUhWG8fE2ADPHCIo57qbO1fXVUEWARdgU5gYIkF4 Kz+dvkpEEiTdRe24zqfn9Bv4lDsihfq3B9zecEuqMj3L88FrMP9VfBJZMbx9N/Pb TUE/FltETdWqMLeIyb7r3P5OPrLRYk6ebgrX96Pb3f0d1/OC8E4Me3RNvGoArmOI f8R0M/zly0lmoJspJFtI2C7BdUIKB/59z/Sz2YC706AJBO0= =mbDG -----END PGP SIGNATURE-----

Any guest issuing a Xenstore command accessing a node using the (illegal) node path "/local/domain/", will crash xenstored due to a clobbered error indicator in xenstored when verifying the node path.

Note that the crash is forced via a failing assert() statement in xenstored. In case xenstored is being built with NDEBUG #defined, an unprivileged guest trying to access the node path "/local/domain/" will result in it no longer being serviced by xenstored, other guests (including dom0) will still be serviced, but xenstored will use up all cpu time it can get.

The Intel EPT paging code uses an optimization to defer flushing of any cached EPT state until the p2m lock is dropped, so that multiple modifications done under the same locked region only issue a single flush.

Freeing of paging structures however is not deferred until the flushing is done, and can result in freed pages transiently being present in cached state. Such stale entries can point to memory ranges not owned by the guest, thus allowing access to unintended memory regions.

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

Xen Security Advisory CVE-2026-23554 / XSA-480 version 3

Use after free of paging structures in EPT

UPDATES IN VERSION 3 ====================

Public release.

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

The Intel EPT paging code uses an optimization to defer flushing of any cached EPT state until the p2m lock is dropped, so that multiple modifications done under the same locked region only issue a single flush.

Freeing of paging structures however is not deferred until the flushing is done, and can result in freed pages transiently being present in cached state. Such stale entries can point to memory ranges not owned by the guest, thus allowing access to unintended memory regions.

IMPACT ======

Privilege escalation, Denial of Service (DoS) affecting the entire host, and information leaks.

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

Xen 4.17 and onwards are vulnerable. Xen 4.16 and older are not vulnerable.

Only x86 Intel systems with EPT support are vulnerable.

Only x86 HVM/PVH guests using HAP can leverage the vulnerability on affected systems.

MITIGATION ==========

There are no mitigations.

CREDITS =======

This issue was discovered by Roger Pau Monné of XenServer.

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.

xsa480.patch xen-unstable - Xen 4.17.x

$ sha256sum xsa480 578f8fec3f34656e085419f6376d43987ffd6ed32e067b4024d3c83ce03a5901 xsa480.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/4UyVfoK9kFAmm5Q1MMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZKDgH/jDFwjlPNV0IQor3c5j9D7L++i5dFugypaF5OI+Q nboD7VEe6y1KexRsPa/a7UAvuabgGdudeS18IS3W34/9TZILZRITo9s3IgEnTfQR qqFlCTxymFuCn8Iptq8SJh37fG3nc9OJ/v28s+0+X9ERnjjjVcjhwcbQ5gQSpKU0 7fAe+IpsO3YOMGb3fgpjhCWMjh9UTHnKOBmObNeDGZ3sXgh8+FYkt6snRs0bYwW4 IcGpmEEgK+Id6n/0sG07Ntntb02EcCz3Vl8G0OflNQj/XOxHBuXbkFc36K2vpUDp dGrzGkIznA00Oz2UNlZrSrMWAQtKuHbB9+H2tU+7BNq+ag8= =RFix -----END PGP SIGNATURE-----

In the context switch logic Xen attempts to skip an IBPB in the case of a vCPU returning to a CPU on which it was the previous vCPU to run. While safe for Xen's isolation between vCPUs, this prevents the guest kernel correctly isolating between tasks. Consider:

1) vCPU runs on CPU A, running task 1. 2) vCPU moves to CPU B, idle gets scheduled on A. Xen skips IBPB. 3) On CPU B, guest kernel switches from task 1 to 2, issuing IBPB. 4) vCPU moves back to CPU A. Xen skips IBPB again.

Now, task 2 is running on CPU A with task 1's training still in the BTB.

Shadow mode tracing code uses a set of per-CPU variables to avoid cumbersome parameter passing. Some of these variables are written to with guest controlled data, of guest controllable size. That size can be larger than the variable, and bounding of the writes was missing.

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

Xen Security Advisory CVE-2024-36350,CVE-2024-36357 / XSA-471 version 3

x86: Transitive Scheduler Attacks

UPDATES IN VERSION 3 ====================

Correct one of the CVEs in the NOTE section at the bottom. It had the wrong year, but correct number and title.

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

Researchers from Microsoft and ETH Zurich have discovered several new speculative sidechannel attacks which bypass current protections. They are detailed in a paper titled "Enter, Exit, Page Fault, Leak: Testing Isolation Boundaries for Microarchitectural Leaks".

Two issues, which AMD have named Transitive Scheduler Attacks, utilise timing information from instruction execution. These are:

CVE-2024-36350: TSA-SQ (TSA in the Store Queues) CVE-2024-36357: TSA-L1 (TSA in the L1 data cache)

For more information, see: https://www.amd.com/content/dam/amd/en/documents/resources/bulletin/technical-guidance-for-mitigating-transient-scheduler-attacks.pdf https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7029.html https://aka.ms/enter-exit-leak

The paper also details other speculative attacks. See below.

IMPACT ======

An attacker might be able to infer data belonging to other contexts, including data belonging to other guests.

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

Systems running all versions of Xen are affected.

Only AMD Fam19h CPUs (Zen3/4 microarchitectures) are believed to be vulnerable. Other AMD CPUs, and CPUs from other manufacturers are not known to be affected.

MITIGATION ==========

There are no mitigations.

RESOLUTION ==========

AMD are producing microcode to address TSA, which adds scrubbing side effects to the VERW instruction. This was included in the firmware fixes for the Entrysign signature vulnerability from ~December 2024, but are also available in an OS-loadable form on older firmware. Consult your dom0 OS vendor and/or hardware vendor for updated microcode.

In addition to the microcode, changes are required to Xen to make use of VERW scrubbing at suitable points.

Applying the appropriate set of attached patches 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.

xsa471/xsa471-??.patch xen-unstable xsa471/xsa471-4.20-??.patch Xen 4.20.x xsa471/xsa471-4.19-??.patch Xen 4.19.x xsa471/xsa471-4.18-??.patch Xen 4.18.x xsa471/xsa471-4.17-??.patch Xen 4.17.x

$ sha256sum xsa471/ 4cc8b54d3cae4864053c4d608061675564cc322c6cd362e33ac59ac4c9371358 xsa471/xsa471-01.patch 9bdfd0ad8d34114e69bb0e264ffdcb176e54211753cc1eed247e73cd3fe752e9 xsa471/xsa471-02.patch 62706c1593cb64bfd053f5ee2e8fa26f5414835c6ef5f694c52a61e18017aa1d xsa471/xsa471-03.patch e06162c55de0b3ca79302ea47c8169079b0f2cd65a48d3e0509677452c9887da xsa471/xsa471-4.17-01.patch 742c59d776c73993c44e72ceada2b83b61fa77a988f5c2c593b6594b4f4078de xsa471/xsa471-4.17-02.patch a8ed5e90e405273115d6a06199de3190319ba12aac33bea17495db42b6a9becc xsa471/xsa471-4.17-03.patch 855c9528d93109a1a673dd8f4feb87a688457908c9dd821d0e1a3326efb19257 xsa471/xsa471-4.17-04.patch f8dbe5c8dbdf921c7f9b4bc7d8234b9bb291df6a4a8cef604284bf4f36947d4e xsa471/xsa471-4.17-05.patch fa2682955663e0966cf285bf79770fe76b387fbf449e1ac64206a6ae4bf79bc4 xsa471/xsa471-4.17-06.patch dc4695aced6ba65e8b16088aefe817e8e4d965cd94e9e3340bd48d77c1369902 xsa471/xsa471-4.17-07.patch 0393a8711805f40eeb936dcca56f5bea174ff94098ffaee7064cd6801eb55099 xsa471/xsa471-4.17-08.patch 346493cc12d9a0fa4154968bc0c8dca9d87e583a25ae9ecd22b8ae2c7bdeae19 xsa471/xsa471-4.17-09.patch 0d652e9a6bb89782036b39160f2db9c1fd1dfc0e659fb4e351f04eb66ffbdba8 xsa471/xsa471-4.17-10.patch ff3ae74f6cfccfaee55f007b2410813068928d20a23729ae2766ddcc65d2e82b xsa471/xsa471-4.17-11.patch 5c6d133f626fdcbc148b596bf3cee1c46260d73fd833aeb6c59cf7c1b315f2b8 xsa471/xsa471-4.17-12.patch acbdca53d713122545ba210a795c4185e842d4cca71802775adc1a4ce971bf3a xsa471/xsa471-4.17-13.patch 4a7fa23b7f501cb88100b55fab13b7315a01fc1e4a3eff46b5d0c867fcc03ca8 xsa471/xsa471-4.17-14.patch 164d626a2f446ad7692bd70ab7e109f8b6259aaea34bfb9f51df68def98a2e62 xsa471/xsa471-4.17-15.patch 35699b19590ccf1872c8da8731b4c47e95cc38d119510e182d196427ea4455f8 xsa471/xsa471-4.17-16.patch 296c95410b6dbf55fa092d15e0eee66125a87b012095f84c550eea54078d0490 xsa471/xsa471-4.17-17.patch 0212aec278afe0dcc6479b756a0c1821d2bfba646fa9ec56f1b9b37ff51756f4 xsa471/xsa471-4.17-18.patch 4e05073bc960b7f43dd383356d1b56fa9c55dc021205678bd8ac456f3a1d00f0 xsa471/xsa471-4.17-19.patch 0d4166420a9e69afe3303d6d3232ee43cf27e88e5bbd8a52a17521934455ed65 xsa471/xsa471-4.18-01.patch 3ff24a622a8ef97af7dddf480dd8c6c12efb8a2dc74ae8d68836543a6cdb8329 xsa471/xsa471-4.18-02.patch fe69ab8c1d45e0d23f58126b22e9914d2269d416cd802619000dc3933c49129e xsa471/xsa471-4.18-03.patch 60b563119ed38a052ed6e6a261b56db5e7b8b40befacd4904d5ce50b2d75d280 xsa471/xsa471-4.18-04.patch 864643c643cfe1f03d28bb36aadcd5bdd1dc7276c30357ea8be1cd1d20ef6f69 xsa471/xsa471-4.18-05.patch 9d5c58339aea8afbeea0bdf34c34cbeb4178ac0a475a32e688317b9810d0f148 xsa471/xsa471-4.18-06.patch 38347e4d096a880cc6d91f09d60277914ad6aa8a6b588913f211097574714ab0 xsa471/xsa471-4.18-07.patch f0db078f811b5c06170f0016fec84a4bbd958b9f8a8d999567c5680d90141c2c xsa471/xsa471-4.18-08.patch 6d2f9de12d113790bbc74327cf94ae08234bec95d88468767462d3a11d0c40d4 xsa471/xsa471-4.18-09.patch 04f63468fca093f8fb5716c0ecafd1ef0be14dd5a464cddc20e719e0c2979980 xsa471/xsa471-4.18-10.patch 5c6e030d1258ce703ddf27fb48ee7b33ca0dbb09657cb38fc7d5b432d215322e xsa471/xsa471-4.18-11.patch 18b17089aa643ae2d6d9d394137a7fe21bf6b8f9743f2237481b68920f3f8f06 xsa471/xsa471-4.18-12.patch d2c35d0a93e9a98fa04623c024a6e152f4d4d6568e6b603ee0cf7f4e4c9dca82 xsa471/xsa471-4.18-13.patch f5b3f0aa8a59033bad4f221709eb4f6f14c82f75ab229ff53ef52b917d0f4021 xsa471/xsa471-4.18-14.patch dc5c0da74f4a6faba0b2af5539cb38a44525379a2f9cafdff18f71cda5280d42 xsa471/xsa471-4.18-15.patch 296c95410b6dbf55fa092d15e0eee66125a87b012095f84c550eea54078d0490 xsa471/xsa471-4.18-16.patch 04c5587d19749a261ca9edc5212d606f2bf577e890c8f4474c55a9c5fe9605d7 xsa471/xsa471-4.18-17.patch 1b10f901d218bafc35d21366e57be89191c0b7c3bcc9def4da5c79bcf93a2e9d xsa471/xsa471-4.18-18.patch d8b010138f5a2773a07902617c65f5d419bae6445410251c9dc1a777b6bf3378 xsa471/xsa471-4.19-01.patch d72ab177637179cccbd32d2dbedfbb399ff4ba59360391e898e3c5fc069803a9 xsa471/xsa471-4.19-02.patch 365ee7e6fb3da83e6238cd4f9138de2018fddb65c1604bbd968e73ce97451fe9 xsa471/xsa471-4.19-03.patch 690cbd2b4b5ce5a855e75cf44c098ca2e231a272d2ebdc1e68d267c5c4e50db0 xsa471/xsa471-4.19-04.patch 82ac6bbca376e33fe1e03569ed76f559f18066000aec6dc72f1722245f5e9a54 xsa471/xsa471-4.19-05.patch 06c475bbb74d86375c17e183bdf74e1ef145a49af2aa237ce69f6ca8e6f78a7c xsa471/xsa471-4.19-06.patch 03bacbdb4cabb3e9eee079a847fa2eda3ff30c86bbfc5d5b1987ee028774a507 xsa471/xsa471-4.19-07.patch b144cea707793e73d6dcbaa0e0ef268bb3cd389e12c080ec687a64a8a3e6ad61 xsa471/xsa471-4.19-08.patch df35ded3dfe5ca84d459eda720699a35e3e49d4b4d461a3f834d05c30b0bcf59 xsa471/xsa471-4.19-09.patch 6719417c0ead056d83ef003cc3b08bf95a3430560fd8f27357c09ca55b6a3993 xsa471/xsa471-4.19-10.patch b7c6ff2f529c6d6cc656b42142d06e5462e652ade57cc2ff5d90320af1234a27 xsa471/xsa471-4.19-11.patch 4b8a05edf04f5b43b1edcf44412ec4be734b011a7b8d2d739ffe0bdc04abce82 xsa471/xsa471-4.19-12.patch e2bca0cd6f66465fdae9e3d251e67ba8a28a96a05201ac939a599dd95a0b3bc6 xsa471/xsa471-4.19-13.patch 8dc65ba84572a090d1bf8ffeb9b5871d9533e4da324fbcdfb1ab32ed83b10fad xsa471/xsa471-4.19-14.patch 2cb102830a29c6c2a898f8f580a9d554c332d6c31dd1608af0fb22b7340f650b xsa471/xsa471-4.19-15.patch 2a873ae56866b9986183e18ea9b70712a15f6df3af299b2d583cbda40a816f58 xsa471/xsa471-4.19-16.patch 77c7634a7d59056f92de619e034f31e63fd6ac6b26dc6e6af65e80fe3e4e5feb xsa471/xsa471-4.20-01.patch 22db1def1859cc7c742b79fee78c994ac4c9cc63daa3663533f324e93e9ef9e0 xsa471/xsa471-4.20-02.patch fb9a103c606552188c05c14092cce084b52b4df75659f4d8013aa30978708ee8 xsa471/xsa471-4.20-03.patch 6930b94a1997b118692a2e0bd5e32bba2e0269b66de4019e3e870304d695c315 xsa471/xsa471-4.20-04.patch 4a67ef27f84eced8fa9cf3ae42d9f79f74a16659ab004fd79a7ee09fce823cf6 xsa471/xsa471-4.20-05.patch 9c62b492be0f1961d5d8062b7d4ac95b9d120e44ca4bf7e009a499fad9c0fcc3 xsa471/xsa471-4.20-06.patch 511728ef65068fa8bda25c31e3fd578aebc8400597d117f31fd2ba436fbb3776 xsa471/xsa471-4.20-07.patch 9a66742ec752a9f58a02f170a4213a22d32bd487e49bfff799800851ba9650e1 xsa471/xsa471-4.20-08.patch 5a02afd655d29b7eba7ac24a8665d64db39994d84e5125a7511f3e5fb7cafacf xsa471/xsa471-4.20-09.patch f55ba571fa668a1ba9fb318c082e684780cc9b8d3c4e7f33db17bf7cc2afcdb3 xsa471/xsa471-4.20-10.patch 4cc8b54d3cae4864053c4d608061675564cc322c6cd362e33ac59ac4c9371358 xsa471/xsa471-4.20-11.patch b180fec77659ce67d24c076301a3d10486afe0c1f224c30b5af7f22f678e8834 xsa471/xsa471-4.20-12.patch 60155cf04e25ad5c95f744dced34c530e0606150e1ca7617e38a9e3d8933eff3 xsa471/xsa471-4.20-13.patch 3d4eb5835d331581fd5c502ea77a0bf3f35c8e12ff9a95d38d32acfed735fefa xsa471/xsa471-4.20-14.patch bc8590f2187d52a727f2354fda9d006087eaae17c34899bec0257ed7e870e7b6 xsa471/xsa471-4.20-15.patch 91c9100a964b0ecaae5ed019e2c846ea0a8a1e5d734e01853be737bb1799d5dd xsa471/xsa471-04.patch 5fce1dfbf084ccabbba9fcb7a8f758cffc1c8ca93a4f1d2a1c6ad49b4fe9e5da xsa471/xsa471-05.patch $

NOTE CONCERNING OTHER SPECULATIVE ATTACKS =========================================

The paper describes two further attack:

CVE-2024-36348: Rogue execution of SMSW CVE-2024-36349: Rogue read of MSRTSCAUX

which are both examples of Rogue System Register Read (sometimes called Spectre-v3a). No fix is planned, because these registers do not typically contain sensitive information. -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmkLSXsMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZYiYH/Rns8DD3t04uGHnr3mR6LP8vMMuq7VxVqzYOfUOu rcfI5W5r8okEvtmb5qdpyCP2UlInh//jXH5nMHrsJl8QRjBC2he81phNvlY+u3Tm CYNb/g8QW0gJNtlyb1GIh0deXl5koyq2wq8hsiT5j6YZH4H1BugU3FdwgPhOf99P Fw646U7iWiMvCemaDvqY2eKiA1nc90jeOuKJvrU8OpQILfcTc/zG+vBy5QnWGvDZ 0EBnpUm/mRDs6dLhySRkV8JYBdcSCNtmieypYjVulda107CChRDK831VnXw5XRru EBhb6mS54DEKwkdTIjuhsT85LRhrFEdIKrqU0LRFRfhNB5g= =soaJ -----END PGP SIGNATURE-----

On 08/04/2025 17:39, Andrew Cooper wrote: On 13/03/2025 3:55 am, Solar Designer wrote: On Sat, Mar 08, 2025 at 01:28:07AM +0000, Andrew Cooper wrote: On 06/03/2025 4:48 am, Solar Designer wrote: On Thu, Mar 06, 2025 at 04:11:25AM +0000, Andrew Cooper wrote: This issue wins points for spite, because the highest risk users are the ones who were taking proactive steps to try and improve their security, betting that AMD's patchloader crypto was sound. OK, so this is to protect legitimate sysadmins from loading malicious microcode inadvertently or via a supply chain attack. Makes sense. Sorry for the delay, I knew there was a distro formally doing this, but I'd lost track of the links.

https://github.com/divestedcg/real-ucode which is packaged for Arch as https://aur.archlinux.org/packages/amd-real-ucode-git (and an equivalent Intel package). Thank you for these followup postings, Andrew! They're very helpful. <snip>

Eddie

When passing through PCI devices, the detach logic in libxl won't remove access permissions to any 64bit memory BARs the device might have. As a result a domain can still have access any 64bit memory BAR when such device is no longer assigned to the domain.

For PV domains the permission leak allows the domain itself to map the memory in the page-tables. For HVM it would require a compromised device model or stubdomain to map the leaked memory into the HVM domain p2m.

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

Xen Security Advisory CVE-2025-58149 / XSA-476

Incorrect removal of permissions on PCI device unplug

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

When passing through PCI devices, the detach logic in libxl won't remove access permissions to any 64bit memory BARs the device might have. As a result a domain can still have access any 64bit memory BAR when such device is no longer assigned to the domain.

For PV domains the permission leak allows the domain itself to map the memory in the page-tables. For HVM it would require a compromised device model or stubdomain to map the leaked memory into the HVM domain p2m.

IMPACT ======

A buggy or malicious PV guest can access memory of PCI devices no longer assigned to it.

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

Xen versions 4.0 and newer are vulnerable.

Only PV guests with PCI passthrough devices can leverage the vulnerability.

Only domains whose PCI devices are managed by the libxl library are affected. This includes the xl toolstack and xapi, which uses the xl toolstack when dealing with PCI devices.

HVM guests are also affected, but accessing the leaked memory requires an additional compromised component on the system.

MITIGATION ==========

Not doing hot unplug of PCI devices will avoid the vulnerability.

Passing through PCI devices to HVM domains only will also limit the impact, as an attacker would require another compromised component to exploit it.

CREDITS =======

This issue was discovered by Jiqian Chen of AMD and diagnosed as a security issue by Roger Pau Monné of XenServer.

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.

xsa476.patch xen-unstable xsa476-4.20.patch Xen 4.20.x - Xen 4.18.x xsa476-4.17.patch Xen 4.17.x

$ sha256sum xsa476 ee4c2fa73d38c5c699006b6317ba53f20343af0593ff9a8c38e7e59b69a0beca xsa476.patch 3b921545f023dc7d9d943d0d661e677711458a917630de14f0871b03db0f2148 xsa476-4.17.patch 5babfaa3680de9950d3391a78e4956b5c18d54eaac9938c6cde2433a2ad3f27d xsa476-4.20.patch $

NOTE REGARDING LACK OF EMBARGO ==============================

This issue was discussed in public already. -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmj7bXYMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZEIEH/ApNvYmMcqqEyOMgGV/VVmEMcXsAy1Ps3rMdDe9U YLsa7ugJLQ/kMI70y0qzws8Uc/kVftl6Z3NbvhpnBMdpurEbZnVuuPtV5I08BF7G 23Qij+NNXSFdUzZVtgqz+POuhpVmrZgEwmg2HXsL1h2KgirUgwh5Nbs4ZuAlbz/f 05tiljIdv4ntqz8sczUxUmtw3XuzcTu0GS8EtPSoAEC5paK72X+5i496qDKpgtqv gdnxqDL2s5ue3G029e9JA3pscVQTMYa3InNiHK28GAM2BW10op1JaxVl/JLN1zzL igpd+u6Fs73qNzcClXQ48YEBkCoTTIdhIrl0mSp4zTfN9dk= =MBxa -----END PGP SIGNATURE-----

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

Some Viridian hypercalls can specify a mask of vCPU IDs as an input, in one of three formats. Xen has boundary checking bugs with all three formats, which can cause out-of-bounds reads and writes while processing the inputs.

CVE-2025-58147. Hypercalls using the HVVPSET Sparse format can cause vpmaskset() to write out of bounds when converting the bitmap to Xen's format.

CVE-2025-58148. Hypercalls using any input format can cause sendipi() to read d->vcpu[] out-of-bounds, and operate on a wild vCPU pointer.

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

Some Viridian hypercalls can specify a mask of vCPU IDs as an input, in one of three formats. Xen has boundary checking bugs with all three formats, which can cause out-of-bounds reads and writes while processing the inputs.

CVE-2025-58147. Hypercalls using the HVVPSET Sparse format can cause vpmaskset() to write out of bounds when converting the bitmap to Xen's format.

CVE-2025-58148. Hypercalls using any input format can cause sendipi() to read d->vcpu[] out-of-bounds, and operate on a wild vCPU pointer.

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

Xen Security Advisory CVE-2025-58147,CVE-2025-58148 / XSA-475 version 2

x86: Incorrect input sanitisation in Viridian hypercalls

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

Public release.

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

Some Viridian hypercalls can specify a mask of vCPU IDs as an input, in one of three formats. Xen has boundary checking bugs with all three formats, which can cause out-of-bounds reads and writes while processing the inputs.

CVE-2025-58147. Hypercalls using the HVVPSET Sparse format can cause vpmaskset() to write out of bounds when converting the bitmap to Xen's format.

CVE-2025-58148. Hypercalls using any input format can cause sendipi() to read d->vcpu[] out-of-bounds, and operate on a wild vCPU pointer.

IMPACT ======

A buggy or malicious guest can cause Denial of Service (DoS) affecting the entire host, information leaks, or elevation of privilege.

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

Xen versions 4.15 and newer are vulnerable. Versions 4.14 and older are not vulnerable.

Only x86 HVM guests which have Viridian enabled can leverage the vulnerability.

With the xl toolstack, this means any viridian= setting in the VM's configuration file.

Note - despite:

viridian=["!hcallremotetlbflush", "!hcallipi", "!exprocessormasks"]

being documented to turns off the relevant functionality, this configuration does not block the relevant hypercalls.

MITIGATION ==========

Not enabling Viridian will avoid the issuse.

CREDITS =======

This issue was discovered by Teddy Astie of Vates

RESOLUTION ==========

Applying the appropriate set of attached patches 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.

xsa475-?.patch xen-unstable - Xen 4.20.x xsa475-4.19-?.patch Xen 4.19.x - Xen 4.17.x

$ sha256sum xsa475 25ba4933e4cf94e81d192f3ba522ec7b258c6e69015a43d169b0325e61957f42 xsa475-1.patch d012541f99c69279b30554e8ea7a7da2790aaa6ff81b0d597f305e4498391369 xsa475-2.patch 6b820b116418e6fd376b6d23ede589e4f86fea4ea775e9afb5c631ceba44d05f xsa475-4.19-1.patch f94b48392179bc08f412ead900a91299ef3a27a6dd4f5fdcf7a152fd65d3a02b xsa475-4.19-2.patch $

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

Deployment of the patches (but not 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.

This is because the mitigations are guest visible changes, and hence could give hints to users about the upcoming vulnerabilities.

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/4UyVfoK9kFAmj3daEMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZnvgIAJzU/Bczr7/Gj3pIqop+rgDsoLw/PU2tGkwhumJQ 0lICxaHWlqrk8cL0y+Ll0nQV4DTwoZbhSm9Bz3S9ZKo6/Qby9YZzo0Tyt9U2OxNU YTpiYGSwrSlCs8cpfj4gwKGzEZ0nNTBTVbAa9UfqIYcvNF4j/L0Tnl6cJOZ/xNhh 8BoH02j+vCF8B8ZInutJjHhKPtrmDta0/md9R4Ydrx4OrLlAoYA4hKnkOuBWfhHg amL1aJ3vk9kNNkP6sO19Vnp5KTawnLGZwN95+FDlDGuh8n8ixKfURvZ9eK8Ycfir naItP4wBkFC9ukzlvGtkwoHPDspxKjtFTYfNvVNvoV6JOWc= =oSQZ -----END PGP SIGNATURE-----

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

There are two issues related to the mapping of pages belonging to other domains: For one, an assertion is wrong there, where the case actually needs handling. A NULL pointer de-reference could result on a release build. This is CVE-2025-58144.

And then the P2M lock isn't held until a page reference was actually obtained (or the attempt to do so has failed). Otherwise the page can not only change type, but even ownership in between, thus allowing domain boundaries to be violated. This is CVE-2025-58145.

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

There are two issues related to the mapping of pages belonging to other domains: For one, an assertion is wrong there, where the case actually needs handling. A NULL pointer de-reference could result on a release build. This is CVE-2025-58144.

And then the P2M lock isn't held until a page reference was actually obtained (or the attempt to do so has failed). Otherwise the page can not only change type, but even ownership in between, thus allowing domain boundaries to be violated. This is CVE-2025-58145.

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

There are multiple issues related to the handling and accessing of guest memory pages in the viridian code:

1. A NULL pointer dereference in the updating of the reference TSC area. This is CVE-2025-27466.

2. A NULL pointer dereference by assuming the SIM page is mapped when a synthetic timer message has to be delivered. This is CVE-2025-58142.

3. A race in the mapping of the reference TSC page, where a guest can get Xen to free a page while still present in the guest physical to machine (p2m) page tables. This is CVE-2025-58143.

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

There are multiple issues related to the handling and accessing of guest memory pages in the viridian code:

1. A NULL pointer dereference in the updating of the reference TSC area. This is CVE-2025-27466.

2. A NULL pointer dereference by assuming the SIM page is mapped when a synthetic timer message has to be delivered. This is CVE-2025-58142.

3. A race in the mapping of the reference TSC page, where a guest can get Xen to free a page while still present in the guest physical to machine (p2m) page tables. This is CVE-2025-58143.

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

There are multiple issues related to the handling and accessing of guest memory pages in the viridian code:

1. A NULL pointer dereference in the updating of the reference TSC area. This is CVE-2025-27466.

2. A NULL pointer dereference by assuming the SIM page is mapped when a synthetic timer message has to be delivered. This is CVE-2025-58142.

3. A race in the mapping of the reference TSC page, where a guest can get Xen to free a page while still present in the guest physical to machine (p2m) page tables. This is CVE-2025-58143.

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

Xen Security Advisory CVE-2025-58146 / XSA-474 version 2

XAPI UTF-8 string handling

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

Public release.

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

There are multiple issues.

1. Updates to the XAPI database sanitise input strings, but try generating the notification using the unsanitised input. This causes the database's event thread to terminate and cease further processing.

2. XAPI's UTF-8 encoder implements v3.0 of the Unicode spec, but XAPI uses libraries which conform to the stricter v3.1 of the Unicode spec. This causes some strings to be accepted as valid UTF-8 by XAPI, but rejected by other libraries in use. Notably, such strings can be entered into the database, after which the database can no longer be loaded.

3. There is no input sanitisation for Map/Set updates on objects in the XAPI database.

IMPACT ======

Buggy or malicious inputs to XAPI can cause a Denial of Service.

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

All versions of XAPI are believed to be vulnerable.

Issues 1 and 2 can be leveraged by guest administrator.

Issue 3 can only be leveraged by an authenticated API user.

MITIGATION ==========

There are no mitigations.

CREDITS =======

This issue was discovered by Edwin Török from XenServer.

RESOLUTION ==========

An updated XAPI, built with the attached patch, needs to be deployed to resolve the issue. If XAPI restarts correctly, no further action is necessary.

If bad strings have been entered into the database, XAPI will get into a restart loop, citing:

[error||0 ||backtrace] Xapi.watchdog failed with exception Xmlm.Error(999:42777, "malformed character stream")

in /var/log/xensource.log roughly every 4 seconds.

To resolve this, the bad characters need stripping manually from the database. In dom0, something along the lines of:

cd /var/xapi service xapi stop cp state.db state.bak iconv -f UTF-8 -t UTF-8//IGNORE < state.db > state.$$ mv state.$$ state.db service xapi start

xsa474.patch XAPI master

$ sha256sum xsa474 e3c7ce7522252b25710062f1c761b5f1e319dab2129fc7c1d9fd6440f9331a9f xsa474.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/4UyVfoK9kFAmjAFVEMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZCBUIAKiQgLyn/B876QeNwBbHk30wylE9ep1okFBuGhBa zhpwNJrJeqnzEfw3ma3v+gDiy/qNp6AKhg8U1GGmF9WyJ4I3c3oA/ATfkN5Kms/W NQnisqExSgo/d8SK0udyk7BCtI0Z+jYxdmnLcPyJgCHOJflZ2CCIpsz6VVvQqq0Y bSgylgrhhQa8+yQ9xWOQHeEzle89JR4JLTRCUzg4AyTUuxaiHGP8zRj9uwgdwkJZ nou+4dQxzE3YhzPjz15j+l9JY8zVUsyzMjsXC0W1EnXuzYGJxuiy8oqaMaqlx7+e hO6fU1iy9ZkIgXPqhAMLlexLkR47Bgw1HLFh4f2XdyqSnBw= =Zist -----END PGP SIGNATURE-----

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

Xen Security Advisory CVE-2025-58144,CVE-2025-58145 / XSA-473 version 2

Arm issues with page refcounting

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

Public release.

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

There are two issues related to the mapping of pages belonging to other domains: For one, an assertion is wrong there, where the case actually needs handling. A NULL pointer de-reference could result on a release build. This is CVE-2025-58144.

And then the P2M lock isn't held until a page reference was actually obtained (or the attempt to do so has failed). Otherwise the page can not only change type, but even ownership in between, thus allowing domain boundaries to be violated. This is CVE-2025-58145.

IMPACT ======

An unprivileged guest can cause a hypervisor crash, causing a Denial of Service (DoS) of the entire host. Privilege escalation and information leaks cannot be ruled out.

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

Xen versions 4.12 and onwards are vulnerable. Xen versions 4.11 and earlier are not vulnerable.

Only Arm systems are affected. x86 systems are not affected.

MITIGATION ==========

There is no known mitigation.

CREDITS =======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION ==========

Applying the appropriate set of attached patches 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.

xsa473-?.patch xen-unstable - Xen 4.19.x xsa473-4.18-?.patch Xen 4.18.x - Xen 4.17.x

$ sha256sum xsa473 e70f71258f1998eddafcdb5f4cb46d98e9dedc529f102b85dfb4e5310faf48eb xsa473-1.patch a501bde6ffb7391387cffe74e3eb9bd5c06d70bd7695aa811d42c75d3903fa59 xsa473-2.patch e8a27f02e57d1a8d956cca9c9ed2db90c328911ff3a9434883baf633a0f3be5c xsa473-4.18-1.patch b2f6f4560d6082e0fb040f7352dda8963ab2dce207efce289131c10b69ebf656 xsa473-4.18-2.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/4UyVfoK9kFAmjAFU8MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ/k0IAMjOW7n+dt0rgaRfwA7twgv8OLLOkuw/+DcPYuR0 tm43Y/5OtqThqmtVqOYdZNA91EQ2rIdh2hkhrCcLI1wrm6qWHvWw4ZUp5VMLyLka u616++Uk3vlc3BrfVEVXzWgGOGYW1o7KP5njiTGcEMR/3BYC3bYBbrf7PHoDgSUR xCmHB/tMCZ/XNkYly1oZntlQTyDjW4lnMJJMTJGXqVOviXmpGs52PRsiClk5kUuB HU8wPkjpw2VQR43iJQWkLQykHnTGWWW/V271br1cJVDHylKaAxETBDUu44JkXTHx voqmAG9cwm6K5Rlh6junqnfW6+UOe6Ib+FGmRXcBZ8zRAV4= =Mloq -----END PGP SIGNATURE-----

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

Xen Security Advisory CVE-2025-27466,CVE-2025-58142,CVE-2025-58143 / XSA-472 version 2

Mutiple vulnerabilities in the Viridian interface

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

Public release.

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

There are multiple issues related to the handling and accessing of guest memory pages in the viridian code:

1. A NULL pointer dereference in the updating of the reference TSC area. This is CVE-2025-27466.

2. A NULL pointer dereference by assuming the SIM page is mapped when a synthetic timer message has to be delivered. This is CVE-2025-58142.

3. A race in the mapping of the reference TSC page, where a guest can get Xen to free a page while still present in the guest physical to machine (p2m) page tables. This is CVE-2025-58143.

IMPACT ======

Denial of Service (DoS) affecting the entire host, information leaks, or elevation of privilege.

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

Xen versions 4.13 and newer are vulnerable. Xen versions 4.12 and older are not vulnerable.

Only x86 HVM guests which have the referencetsc or stimer viridian extensions enabled are vulnerable.

MITIGATION ==========

Not enabling the referencetsc and stimer viridian extensions will avoid the issues.

CREDITS =======

This issue was discovered by Roger Pau Monné of XenServer.

RESOLUTION ==========

Applying the appropriate set of attached patches 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.

xsa472-?.patch xen-unstable - Xen 4.17.x

$ sha256sum xsa472 16e14b3cc87800c08d96adc18e66aa4a20a77834af12b9cdd01d739882f07b7d xsa472-1.patch 4be6a1066fbec367e8c9883240cec2a78671d484928d51ac5fb82e2c539e38ca xsa472-2.patch 9e1972a2b5a7a817b25cad0fa80c983198bb73a2788a4d0b5cdcaca4518a57cf xsa472-3.patch $

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

Deployment of the patches (but not 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.

This is because the mitigations are guest visible changes, and hence could give hints to users about the upcoming vulnerabilities.

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/4UyVfoK9kFAmjAFT8MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZGV8H+QEb73eX4Nf/BSKpeLxzO5vpieWv9vFX83Tq9/LH KFQKbz4Y13XjtrxEpQhnZCYBEjgByBECrCnngaqjT8P3G17fhiEp2pMgMsU783mz TPtmdDcC63WGNyqB/7j3jxDLuCscPKKGjS+DHmcIbiV9H820EYQi83mWOGNwXRQP pYaMz5HSO15YypxKgK4i+piVceTS/fL0dclFU/vY13bq9sCqE/E4XRsClPgk1ryS LqUBtXbQJfxSK9asMxd0BLozVsWNVgZ6e2XTWpPf/T5EBoOo+qhQ2XaRmGCyVi98 D5t8BJ0HV83Ptik37QlosjsRbtogPXpOiaPsFmB15WFlxk8= =/zd8 -----END PGP SIGNATURE-----

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

Xen Security Advisory CVE-2024-36350,CVE-2024-36357 / XSA-471 version 2

x86: Transitive Scheduler Attacks

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

The fix for this issue uncovered a pre-existing bug with the handling of timers and broke S3 suspend on certain systems. The following patch in xen.git#master resolves the issue:

757abedabbb6 x86/suspend: unconditionally raise a timer softirq on resume

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

Researchers from Microsoft and ETH Zurich have discovered several new speculative sidechannel attacks which bypass current protections. They are detailed in a paper titled "Enter, Exit, Page Fault, Leak: Testing Isolation Boundaries for Microarchitectural Leaks".

Two issues, which AMD have named Transitive Scheduler Attacks, utilise timing information from instruction execution. These are:

CVE-2024-36350: TSA-SQ (TSA in the Store Queues) CVE-2024-36357: TSA-L1 (TSA in the L1 data cache)

For more information, see: https://www.amd.com/content/dam/amd/en/documents/resources/bulletin/technical-guidance-for-mitigating-transient-scheduler-attacks.pdf https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7029.html https://aka.ms/enter-exit-leak

The paper also details other speculative attacks. See below.

IMPACT ======

An attacker might be able to infer data belonging to other contexts, including data belonging to other guests.

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

Systems running all versions of Xen are affected.

Only AMD Fam19h CPUs (Zen3/4 microarchitectures) are believed to be vulnerable. Other AMD CPUs, and CPUs from other manufacturers are not known to be affected.

MITIGATION ==========

There are no mitigations.

RESOLUTION ==========

AMD are producing microcode to address TSA, which adds scrubbing side effects to the VERW instruction. This was included in the firmware fixes for the Entrysign signature vulnerability from ~December 2024, but are also available in an OS-loadable form on older firmware. Consult your dom0 OS vendor and/or hardware vendor for updated microcode.

In addition to the microcode, changes are required to Xen to make use of VERW scrubbing at suitable points.

Applying the appropriate set of attached patches 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.

xsa471/xsa471-??.patch xen-unstable xsa471/xsa471-4.20-??.patch Xen 4.20.x xsa471/xsa471-4.19-??.patch Xen 4.19.x xsa471/xsa471-4.18-??.patch Xen 4.18.x xsa471/xsa471-4.17-??.patch Xen 4.17.x

$ sha256sum xsa471/ 4cc8b54d3cae4864053c4d608061675564cc322c6cd362e33ac59ac4c9371358 xsa471/xsa471-01.patch 9bdfd0ad8d34114e69bb0e264ffdcb176e54211753cc1eed247e73cd3fe752e9 xsa471/xsa471-02.patch 62706c1593cb64bfd053f5ee2e8fa26f5414835c6ef5f694c52a61e18017aa1d xsa471/xsa471-03.patch e06162c55de0b3ca79302ea47c8169079b0f2cd65a48d3e0509677452c9887da xsa471/xsa471-4.17-01.patch 742c59d776c73993c44e72ceada2b83b61fa77a988f5c2c593b6594b4f4078de xsa471/xsa471-4.17-02.patch a8ed5e90e405273115d6a06199de3190319ba12aac33bea17495db42b6a9becc xsa471/xsa471-4.17-03.patch 855c9528d93109a1a673dd8f4feb87a688457908c9dd821d0e1a3326efb19257 xsa471/xsa471-4.17-04.patch f8dbe5c8dbdf921c7f9b4bc7d8234b9bb291df6a4a8cef604284bf4f36947d4e xsa471/xsa471-4.17-05.patch fa2682955663e0966cf285bf79770fe76b387fbf449e1ac64206a6ae4bf79bc4 xsa471/xsa471-4.17-06.patch dc4695aced6ba65e8b16088aefe817e8e4d965cd94e9e3340bd48d77c1369902 xsa471/xsa471-4.17-07.patch 0393a8711805f40eeb936dcca56f5bea174ff94098ffaee7064cd6801eb55099 xsa471/xsa471-4.17-08.patch 346493cc12d9a0fa4154968bc0c8dca9d87e583a25ae9ecd22b8ae2c7bdeae19 xsa471/xsa471-4.17-09.patch 0d652e9a6bb89782036b39160f2db9c1fd1dfc0e659fb4e351f04eb66ffbdba8 xsa471/xsa471-4.17-10.patch ff3ae74f6cfccfaee55f007b2410813068928d20a23729ae2766ddcc65d2e82b xsa471/xsa471-4.17-11.patch 5c6d133f626fdcbc148b596bf3cee1c46260d73fd833aeb6c59cf7c1b315f2b8 xsa471/xsa471-4.17-12.patch acbdca53d713122545ba210a795c4185e842d4cca71802775adc1a4ce971bf3a xsa471/xsa471-4.17-13.patch 4a7fa23b7f501cb88100b55fab13b7315a01fc1e4a3eff46b5d0c867fcc03ca8 xsa471/xsa471-4.17-14.patch 164d626a2f446ad7692bd70ab7e109f8b6259aaea34bfb9f51df68def98a2e62 xsa471/xsa471-4.17-15.patch 35699b19590ccf1872c8da8731b4c47e95cc38d119510e182d196427ea4455f8 xsa471/xsa471-4.17-16.patch 296c95410b6dbf55fa092d15e0eee66125a87b012095f84c550eea54078d0490 xsa471/xsa471-4.17-17.patch 0212aec278afe0dcc6479b756a0c1821d2bfba646fa9ec56f1b9b37ff51756f4 xsa471/xsa471-4.17-18.patch 4e05073bc960b7f43dd383356d1b56fa9c55dc021205678bd8ac456f3a1d00f0 xsa471/xsa471-4.17-19.patch 0d4166420a9e69afe3303d6d3232ee43cf27e88e5bbd8a52a17521934455ed65 xsa471/xsa471-4.18-01.patch 3ff24a622a8ef97af7dddf480dd8c6c12efb8a2dc74ae8d68836543a6cdb8329 xsa471/xsa471-4.18-02.patch fe69ab8c1d45e0d23f58126b22e9914d2269d416cd802619000dc3933c49129e xsa471/xsa471-4.18-03.patch 60b563119ed38a052ed6e6a261b56db5e7b8b40befacd4904d5ce50b2d75d280 xsa471/xsa471-4.18-04.patch 864643c643cfe1f03d28bb36aadcd5bdd1dc7276c30357ea8be1cd1d20ef6f69 xsa471/xsa471-4.18-05.patch 9d5c58339aea8afbeea0bdf34c34cbeb4178ac0a475a32e688317b9810d0f148 xsa471/xsa471-4.18-06.patch 38347e4d096a880cc6d91f09d60277914ad6aa8a6b588913f211097574714ab0 xsa471/xsa471-4.18-07.patch f0db078f811b5c06170f0016fec84a4bbd958b9f8a8d999567c5680d90141c2c xsa471/xsa471-4.18-08.patch 6d2f9de12d113790bbc74327cf94ae08234bec95d88468767462d3a11d0c40d4 xsa471/xsa471-4.18-09.patch 04f63468fca093f8fb5716c0ecafd1ef0be14dd5a464cddc20e719e0c2979980 xsa471/xsa471-4.18-10.patch 5c6e030d1258ce703ddf27fb48ee7b33ca0dbb09657cb38fc7d5b432d215322e xsa471/xsa471-4.18-11.patch 18b17089aa643ae2d6d9d394137a7fe21bf6b8f9743f2237481b68920f3f8f06 xsa471/xsa471-4.18-12.patch d2c35d0a93e9a98fa04623c024a6e152f4d4d6568e6b603ee0cf7f4e4c9dca82 xsa471/xsa471-4.18-13.patch f5b3f0aa8a59033bad4f221709eb4f6f14c82f75ab229ff53ef52b917d0f4021 xsa471/xsa471-4.18-14.patch dc5c0da74f4a6faba0b2af5539cb38a44525379a2f9cafdff18f71cda5280d42 xsa471/xsa471-4.18-15.patch 296c95410b6dbf55fa092d15e0eee66125a87b012095f84c550eea54078d0490 xsa471/xsa471-4.18-16.patch 04c5587d19749a261ca9edc5212d606f2bf577e890c8f4474c55a9c5fe9605d7 xsa471/xsa471-4.18-17.patch 1b10f901d218bafc35d21366e57be89191c0b7c3bcc9def4da5c79bcf93a2e9d xsa471/xsa471-4.18-18.patch d8b010138f5a2773a07902617c65f5d419bae6445410251c9dc1a777b6bf3378 xsa471/xsa471-4.19-01.patch d72ab177637179cccbd32d2dbedfbb399ff4ba59360391e898e3c5fc069803a9 xsa471/xsa471-4.19-02.patch 365ee7e6fb3da83e6238cd4f9138de2018fddb65c1604bbd968e73ce97451fe9 xsa471/xsa471-4.19-03.patch 690cbd2b4b5ce5a855e75cf44c098ca2e231a272d2ebdc1e68d267c5c4e50db0 xsa471/xsa471-4.19-04.patch 82ac6bbca376e33fe1e03569ed76f559f18066000aec6dc72f1722245f5e9a54 xsa471/xsa471-4.19-05.patch 06c475bbb74d86375c17e183bdf74e1ef145a49af2aa237ce69f6ca8e6f78a7c xsa471/xsa471-4.19-06.patch 03bacbdb4cabb3e9eee079a847fa2eda3ff30c86bbfc5d5b1987ee028774a507 xsa471/xsa471-4.19-07.patch b144cea707793e73d6dcbaa0e0ef268bb3cd389e12c080ec687a64a8a3e6ad61 xsa471/xsa471-4.19-08.patch df35ded3dfe5ca84d459eda720699a35e3e49d4b4d461a3f834d05c30b0bcf59 xsa471/xsa471-4.19-09.patch 6719417c0ead056d83ef003cc3b08bf95a3430560fd8f27357c09ca55b6a3993 xsa471/xsa471-4.19-10.patch b7c6ff2f529c6d6cc656b42142d06e5462e652ade57cc2ff5d90320af1234a27 xsa471/xsa471-4.19-11.patch 4b8a05edf04f5b43b1edcf44412ec4be734b011a7b8d2d739ffe0bdc04abce82 xsa471/xsa471-4.19-12.patch e2bca0cd6f66465fdae9e3d251e67ba8a28a96a05201ac939a599dd95a0b3bc6 xsa471/xsa471-4.19-13.patch 8dc65ba84572a090d1bf8ffeb9b5871d9533e4da324fbcdfb1ab32ed83b10fad xsa471/xsa471-4.19-14.patch 2cb102830a29c6c2a898f8f580a9d554c332d6c31dd1608af0fb22b7340f650b xsa471/xsa471-4.19-15.patch 2a873ae56866b9986183e18ea9b70712a15f6df3af299b2d583cbda40a816f58 xsa471/xsa471-4.19-16.patch 77c7634a7d59056f92de619e034f31e63fd6ac6b26dc6e6af65e80fe3e4e5feb xsa471/xsa471-4.20-01.patch 22db1def1859cc7c742b79fee78c994ac4c9cc63daa3663533f324e93e9ef9e0 xsa471/xsa471-4.20-02.patch fb9a103c606552188c05c14092cce084b52b4df75659f4d8013aa30978708ee8 xsa471/xsa471-4.20-03.patch 6930b94a1997b118692a2e0bd5e32bba2e0269b66de4019e3e870304d695c315 xsa471/xsa471-4.20-04.patch 4a67ef27f84eced8fa9cf3ae42d9f79f74a16659ab004fd79a7ee09fce823cf6 xsa471/xsa471-4.20-05.patch 9c62b492be0f1961d5d8062b7d4ac95b9d120e44ca4bf7e009a499fad9c0fcc3 xsa471/xsa471-4.20-06.patch 511728ef65068fa8bda25c31e3fd578aebc8400597d117f31fd2ba436fbb3776 xsa471/xsa471-4.20-07.patch 9a66742ec752a9f58a02f170a4213a22d32bd487e49bfff799800851ba9650e1 xsa471/xsa471-4.20-08.patch 5a02afd655d29b7eba7ac24a8665d64db39994d84e5125a7511f3e5fb7cafacf xsa471/xsa471-4.20-09.patch f55ba571fa668a1ba9fb318c082e684780cc9b8d3c4e7f33db17bf7cc2afcdb3 xsa471/xsa471-4.20-10.patch 4cc8b54d3cae4864053c4d608061675564cc322c6cd362e33ac59ac4c9371358 xsa471/xsa471-4.20-11.patch b180fec77659ce67d24c076301a3d10486afe0c1f224c30b5af7f22f678e8834 xsa471/xsa471-4.20-12.patch 60155cf04e25ad5c95f744dced34c530e0606150e1ca7617e38a9e3d8933eff3 xsa471/xsa471-4.20-13.patch 3d4eb5835d331581fd5c502ea77a0bf3f35c8e12ff9a95d38d32acfed735fefa xsa471/xsa471-4.20-14.patch bc8590f2187d52a727f2354fda9d006087eaae17c34899bec0257ed7e870e7b6 xsa471/xsa471-4.20-15.patch 91c9100a964b0ecaae5ed019e2c846ea0a8a1e5d734e01853be737bb1799d5dd xsa471/xsa471-04.patch 5fce1dfbf084ccabbba9fcb7a8f758cffc1c8ca93a4f1d2a1c6ad49b4fe9e5da xsa471/xsa471-05.patch $

NOTE CONCERNING OTHER SPECULATIVE ATTACKS =========================================

The paper describes two further attack:

CVE-2024-36348: Rogue execution of SMSW CVE-2045-36349: Rogue read of MSRTSCAUX

which are both examples of Rogue System Register Read (sometimes called Spectre-v3a). No fix is planned, because these registers do not typically contain sensitive information. -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmiwdxIMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZuDgIAJBfOoZft1bBbdDkgVuyuxzdvZHPHqENABOoWi7P 1phCJ20Aq4ZA9hezEzWpy2i84zAoJuxyZUAKfi86uPIlTfOjAhvaTC6jcabdKYHA IGC3ldZTXe2X9z5EQKAzkUiD0GslP2SBnFwtUq+G84USNNT7ZlwV9f5ECW3WvRFA R5YvH3s8UT7aZKelUy07GM246eFXj+PjFE5mZTlRdu0n1gZzwvrtALKrTS7bt806 XwA7Iz/W1R53DoPrvKhop/bzGb8L8i+UMHwzSAgWfi7n5PHq0dQjACwBY7ktIfQK F+yky+M3LG+9xxWCkjXnPMUjEwFRxlsNuJiLe2QQ5et7TLM= =wkVe -----END PGP SIGNATURE-----

Certain instructions need intercepting and emulating by Xen. In some cases Xen emulates the instruction by replaying it, using an executable stub. Some instructions may raise an exception, which is supposed to be handled gracefully. Certain replayed instructions have additional logic to set up and recover the changes to the arithmetic flags.

For replayed instructions where the flags recovery logic is used, the metadata for exception handling was incorrect, preventing Xen from handling the the exception gracefully, treating it as fatal instead.