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

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

On 06/03/2025 4:48 am, Solar Designer wrote: Under Host UEFI Secure Boot, there is a security boundary between kernel code and root.  Part of the requirement is "no unsigned code running privileged", and while this is technically a grey area (the malicious blob is signed; it's just not signed by AMD), it's also easy to argue that root definitely shouldn't be able to load a malicious microcode, just like it shouldn't be able to swap out the kernel with an unsigned one and reboot. Yes, but can't Xen's and the kernel's new protections be bypassed by MSR access via /dev/cpu//msr? The AMD microcode loader released by Google now doesn't appear to require more than that:

https://github.com/google/security-research/blob/master/pocs/cpus/entrysign/zentool/loader.c For Linux, /dev/cpu//msr isn't available when lockdown mode is active.

For Xen, guests can't load microcode at all (writes to the relevant MSRs are simply swallowed).  Actually loading microcode is done via hypercall, restricted to privileged domains, and digest checking can't be disabled without a reboot (or a livepatch, which in a UEFI-SB model needs to itself be signed).

Answering Bastian's question from the other fork of this thread (sorry, I'm not CC'd).

Maintaining the hash list is a concern, but in the immediate term, the relevant maintainers in Linux and Xen.

Something better is being worked on, but there are challenges beyond just technical ones.

~Andrew

On Wed, Mar 05, 2025 at 07:11:23PM +0000, Andrew Cooper wrote: See:

https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html

Right now there are four known but (reasonably) benign microcodes from a non-AMD source.  However, there is a tool to sign arbitrary microcode.

In Xen, we've provided a stopgap mitigation to perform extra checks on microcode load on affected CPU families.  This is a SHA2 digest check against hashes with believed-good provenance.  This is staging only for now, in case it is overly disruptive.

This will not protect against an already-compromised platform, but it will prevent an uncompromised system becoming compromised via Xen's microcode loading capabilities. Thank you, Andrew!

Maybe you can also clarify what Xen's threat model is here, and how this mitigation fits into it?

Specifically, what are "Xen's microcode loading capabilities" and are they in any way more exposed than the host system's root account? Even with Xen's mitigation above, host root can still load microcode without Xen involvement, right? Unless you block (at least) MSR access and kernel module loading?

Also, by "uncompromised system", do you specifically mean uncompromised at microcode level? If the threat is from a Xen administrator, then perhaps that's a partial security compromise already, just not yet extended to microcode.

These things may be obvious to someone more familiar with Xen, but your message and answers to the above are also interesting to the rest of us. On affected systems, the only complete fix is a firmware update.  This is a very firmly recommended course of action.

Sincerely,

~Andrew, on behalf of the Xen Security Team. Alexander

On 12/11/2024 5:17 pm, Demi Marie Obenour wrote: On Tue, Nov 12, 2024 at 12:05:47PM +0000, Xen Security wrote: Only PVH guests can leverage the vulnerability. HVM and PV guests cannot leverage the vulnerability. Note that PV guests when run inside the (PVH) shim can't leverage the vulnerability. Is this unconditional (perhaps because the relevant data gets zeroed out by the shim), or does it only apply when the PV guest can't extract data from the shim's memory? For instance, 32-bit PV guests aren't security supported anymore, but the PV shim isn't supposed to rely on the security of the shim itself, only of the rest of the system. Data are leaked into the PVShim guest, but it is the shim Xen (exclusively) which has access to the ACPI tables.

The guest which has been shim'd can't architecturally access the leaked data.

~Andrew

The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in "standard" mode. Locking involved there has an unusual discipline, leaving a lock acquired past the return from the function that acquired it. This behavior results in a problem when emulating an instruction with two memory accesses, both of which touch VGA memory (plus some further constraints which aren't relevant here). When emulating the 2nd access, the lock that is already being held would be attempted to be re-acquired, resulting in a deadlock.

This deadlock was already found when the code was first introduced, but was analysed incorrectly and the fix was incomplete. Analysis in light of the new finding cannot find a way to make the existing locking discipline work.

In staging, this logic has all been removed because it was discovered to be accidentally disabled since Xen 4.7. Therefore, we are fixing the locking problem by backporting the removal of most of the feature. Note that even with the feature disabled, the lock would still be acquired for any accesses to the VGA MMIO region.

For a brief summary of Xapi terminology, see:

https://xapi-project.github.io/xen-api/overview.html#object-model-overview

Xapi contains functionality to backup and restore metadata about Virtual Machines and Storage Repositories (SRs).

The metadata itself is stored in a Virtual Disk Image (VDI) inside an SR. This is used for two purposes; a general backup of metadata (e.g. to recover from a host failure if the filer is still good), and Portable SRs (e.g. using an external hard drive to move VMs to another host).

Metadata is only restored as an explicit administrator action, but occurs in cases where the host has no information about the SR, and must locate the metadata VDI in order to retrieve the metadata.

The metadata VDI is located by searching (in UUID alphanumeric order) each VDI, mounting it, and seeing if there is a suitable metadata file present. The first matching VDI is deemed to be the metadata VDI, and is restored from.

In the general case, the content of VDIs are controlled by the VM owner, and should not be trusted by the host administrator.

A malicious guest can manipulate its disk to appear to be a metadata backup.

A guest cannot choose the UUIDs of its VDIs, but a guest with one disk has a 50% chance of sorting ahead of the legitimate metadata backup. A guest with two disks has a 75% chance, etc.

An attacker with local access to a system (either through a disk or external drive) can present a modified XFS partition to grub-legacy in such a way to exploit a memory corruption in grub’s XFS file system implementation.

Closing of an event channel in the Linux kernel can result in a deadlock. This happens when the close is being performed in parallel to an unrelated Xen console action and the handling of a Xen console interrupt in an unprivileged guest.

The closing of an event channel is e.g. triggered by removal of a paravirtual device on the other side. As this action will cause console messages to be issued on the other side quite often, the chance of triggering the deadlock is not neglectable.

Note that 32-bit Arm-guests are not affected, as the 32-bit Linux kernel on Arm doesn't use queued-RW-locks, which are required to trigger the issue (on Arm32 a waiting writer doesn't block further readers to get the lock).

On 2023-10-03 22:37:08 +0100 (+0100), Andrew Cooper wrote: [...] If you have a proposal for how you'd prefer it to be done, I'll see what I can do. Perhaps BCC oss-security, or just send out a second mail? When I send advisories, I prepare two basically identical E-mail messages: one to the project's announcement list and one to oss-security (signing both of them). It seems like this is the most common approach to avoiding cross-posting between lists. -- Jeremy Stanley

On 26/09/2023 5:09 pm, Solar Designer wrote: On Tue, Sep 26, 2023 at 01:15:55AM +0100, Andrew Cooper wrote: On 25/09/2023 7:28 pm, Solar Designer wrote: Maybe directly probing for the bug is an option? Perhaps can be done within one thread (where the bug doesn't have security impact, but is detectable anyway, no)? Unfortunately, direct probing is usually the wrong thing to rely on.

Under virt, one common scenario is that you boot on one system, then get migrated to a different one.  Obviously, it's up to the hypervisor to ensure that the architectural feature still match, but the microarchitecture really does change.

If you probe at boot and positively identify an issue to work around, great.  But as a VM you may not get a heads up that you changed microarchitecture, and even if you do, you don't rescan for everything you ran at boot.

The CPUID bits allow microarchitectural details to be expressed as architectural, and allow a hypervisor to state "here or someone you might move to, the following safety property does not hold." I was thinking re-probing after possible VM migration, just like you would presumably retest a CPUID bit. I did enquire about this, but the Linux maintainers and Microsoft were distinctly unreceptive to the idea.  Not that I blame them - it's hard enough to do late microcode loading, livepatching and activation of new safety properties when the uarch isn't moving underfoot. However, in this case probing can lead to false negatives if the other thread issues a DIV too or an unexpected context switch occurs. Yes, many things become racy under virt, hence why we try our best to stick to architecturally enumerated properties. Do you know if only the quotient leaks, or also the remainder? In the below, I assume the remainder leaks as well. I'm afraid I don't know. The original paper says just the quotient, but it also says there are no leaks across privilege boundaries. Is the original paper public? https://www.usenix.org/system/files/usenixsecurity23-hofmann.pdf

Section 8.2.1 for the results specific to divides. Meanwhile, I observe a difference between Linux and Xen fixes - Linux uses native-sized DIV and you use byte-sized, as a clever way not to clobber RDX and maybe achieve lower latency. Speaking of which:

$ git clone https://github.com/InstLatx64/InstLatx64 $ grep -r ': DIV . 0/' InstLatx64/AuthenticAMD/Zen.txt InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 409 X86 : DIV r8 0/ 8b L: [no true dep.] T: 4.14ns= 13.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 413 X86 : DIV r8 0/ 4b L: [no true dep.] T: 4.13ns= 13.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 422 X86 : DIV r16 0/16b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 426 X86 : DIV r16 0/ 8b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 435 X86 : DIV r32 0/32b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 439 X86 : DIV r32 0/16b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 449 AMD64 : DIV r64 0/64b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 453 AMD64 : DIV r64 0/32b L: [no true dep.] T: 4.45ns= 14.00c

Looks like maybe not that much difference, after all, if this data applies. Agner Fogh's manuals have a little more information, and importantly give the upper bound which tops out at 47 cycles.

There is at least a 1 cycle change in latency between the byte and non-byte forms, which I suspect is down to the non-byte forms needing to consume an extra input register before starting.

But the main reason for choosing the byte form is indeed fewer moving parts to worry about in the critical sections, where one wrong instruction can render all protections moot. Thank you for sharing so much detail and thoughts on this, Andrew! You're welcome.

~Andrew

On Tue, Sep 26, 2023 at 01:15:55AM +0100, Andrew Cooper wrote: On 25/09/2023 7:28 pm, Solar Designer wrote: Maybe directly probing for the bug is an option? Perhaps can be done within one thread (where the bug doesn't have security impact, but is detectable anyway, no)? Unfortunately, direct probing is usually the wrong thing to rely on.

Under virt, one common scenario is that you boot on one system, then get migrated to a different one.  Obviously, it's up to the hypervisor to ensure that the architectural feature still match, but the microarchitecture really does change.

If you probe at boot and positively identify an issue to work around, great.  But as a VM you may not get a heads up that you changed microarchitecture, and even if you do, you don't rescan for everything you ran at boot.

The CPUID bits allow microarchitectural details to be expressed as architectural, and allow a hypervisor to state "here or someone you might move to, the following safety property does not hold." I was thinking re-probing after possible VM migration, just like you would presumably retest a CPUID bit. However, in this case probing can lead to false negatives if the other thread issues a DIV too or an unexpected context switch occurs. Do you know if only the quotient leaks, or also the remainder? In the below, I assume the remainder leaks as well. I'm afraid I don't know. The original paper says just the quotient, but it also says there are no leaks across privilege boundaries. Is the original paper public?

Meanwhile, I observe a difference between Linux and Xen fixes - Linux uses native-sized DIV and you use byte-sized, as a clever way not to clobber RDX and maybe achieve lower latency. Speaking of which:

$ git clone https://github.com/InstLatx64/InstLatx64 $ grep -r ': DIV . 0/' InstLatx64/AuthenticAMD/Zen.txt InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 409 X86 : DIV r8 0/ 8b L: [no true dep.] T: 4.14ns= 13.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 413 X86 : DIV r8 0/ 4b L: [no true dep.] T: 4.13ns= 13.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 422 X86 : DIV r16 0/16b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 426 X86 : DIV r16 0/ 8b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 435 X86 : DIV r32 0/32b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 439 X86 : DIV r32 0/16b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 449 AMD64 : DIV r64 0/64b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 453 AMD64 : DIV r64 0/32b L: [no true dep.] T: 4.45ns= 14.00c

Looks like maybe not that much difference, after all, if this data applies.

Thank you for sharing so much detail and thoughts on this, Andrew!

Alexander

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

Xen Security Advisory CVE-2023-20588 / XSA-439 version 2

x86/AMD: Divide speculative information leak

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

Version 1 accidentally linked to the wrong AMD bulletin. This has been corrected in v2. All other information in v1 is believed to be correct.

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

In the Zen1 microarchitecure, there is one divider in the pipeline which services uops from both threads. In the case of #DE, the latched result from the previous DIV to execute will be forwarded speculatively.

This is a covert channel that allows two threads to communicate without any system calls. In also allows userspace to obtain the result of the most recent DIV instruction executed (even speculatively) in the core, which can be from a higher privilege context.

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

IMPACT ======

An attacker might be able to infer data from a different execution context on the same CPU core.

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

All versions of Xen are vulnerable.

Only AMD Zen1 CPUs are believed to be vulnerable.

MITIGATION ==========

There is no mitigation.

RESOLUTION ==========

The patches for Xen overwrite the buffer in the divider on the return-to-guest path.

However, as with some prior speculative vulnerabilities, the fix is only effective in combination with disabling SMT. For the same reasons as before, Xen does not disable SMT by default.

The system administrator is required to risk-assess their workload, and choose whether to enable or disable SMT. Xen will issue a warning if SMT is active and the user has not provided an explicit choice via the smt=<bool> command line option.

Details of the vulnerability became public before the Xen patches were complete. Hence the patches are already applied to the appropriate trees. They are:

Xen-unstable: 1c18d7377453^..b5926c6ecf05 Xen 4.17: d2d2dcae879c^..9ac2f49f5fa3 Xen 4.16: 08539e8315fd^..de751c3d906d Xen 4.15: db3386e6cad6^..d7b78041dc81 -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmURwLwMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZMjgIAI+pm7OnUq8EbuD6eyB7yDKBRwm9U7Hu2yrO47f0 CHO/HdMANfx0nCbpKS8+7GXa2gooJXgp3Fo0NGri2G0+hzXNQTsaGnMEMgBV7O0M OXYzao39dhPATP4hi5bm0xPTZ+3zMaP06xvl7JqNqsPK8GFz/cZr/Hsz5r2boZRO 3FXEmbgsG2KTR5+HrSNoeA3LM9aoUqEiIq6oGxLaTr7UI6xK4FL5VFloWhS0r9yp gD7HHP6NlV1Ysxt1xKCxf109HrzWEvih/Gd8hG6eqiHR+i2zyS1hna8Ll/sRFkOO x9FpYHljtb3WKX9bUh4aZXdoAWRW0aR+SWcXToPSk5aFJiE= =W6vz -----END PGP SIGNATURE-----

On 16/08/2023 5:41 pm, Solar Designer wrote: On Tue, Aug 08, 2023 at 07:18:51PM +0100, Andrew Cooper wrote: On 08/08/2023 7:00 pm, Solar Designer wrote: + / + Microcode is the preferred mitigation, in terms of performance. + However, without microcode, this chickenbit (specific to the Zen2 + uarch) disables Floating Point Mov-Elimination to mitigate the + issue. + / + val &= ~chickenbit; + if (sig->rev < goodrev) + val |= chickenbit;

This leaves me wondering: why have this line at all? I understand Xen wanting to enable the chicken bit on vulnerable CPUs, but why disable it on other AMD CPUs? If someone or something had enabled the bit, that's probably intentional, and even if not it probably shouldn't be Xen's business to alter CPU behavior beyond what's necessary for Xen itself to work reliably and securely.

Am I missing something? There is an earlier exit in this function for any non-Zen2 system.

So here, we are strictly on Zen2 (all vulnerable), and either have good microcode or not.

The microcode fix is far more performant than the chickenbit. Sure, but that's orthogonal to my concern, which was about areas of responsibility and control (such as sysadmin vs. tools).

Anyway, it was pointed out to me off-list that Linux kernel does the same thing, also explicitly disabling chickenbit when deemed safe:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=522b1d69219d8f083173819fde04f994aa051a98

+ if (!cpuhaszenbleedmicrocode()) { + prnoticeonce("Zenbleed: please update your microcode for the most optimal fix\n"); + msrsetbit(MSRAMD64DECFG, MSRAMD64DECFGZEN2FPBACKUPFIXBIT); + } else { + msrclearbit(MSRAMD64DECFG, MSRAMD64DECFGZEN2FPBACKUPFIXBIT); + }

So at least it's a consistent approach by these two projects, and a reason for Xen to be doing it this way. It is not a coincidence that Xen and Linux are similar here.  The areas of responsibility aspect was raised during review - we did consider combining with the old value.

AMD's position AIUI is that prior to Zenbleed, this bit was unsupported and not used.  Therefore we went for the simpler approach (and as you saw, still managed to screw that up).

~Andrew

On 08/08/2023 7:00 pm, Solar Designer wrote: On Mon, Jul 31, 2023 at 05:00:35PM +0000, Xen. org security team wrote: The patch provided with earlier versions was buggy. It unintentionally disable more bits than expected in the control register. The contents of this register is not generally known, so the effects on the system are unknown.

A patch correcting this error has been committed and backported to all stable trees which got the XSA-433 fix originally. Additionally, it is attached to this advisory as xsa433-bugfix.patch, and applicable to all branches in this form. where xsa433-bugfix.patch includes this description: This line:

val &= ~chickenbit;

ends up truncating val to 32 bits, and turning off various errata workarounds in Zen2 systems. and that patch then corrects the truncation by changing the type of the chickenbit variable to 64-bit. The context is:

+ / + Microcode is the preferred mitigation, in terms of performance. + However, without microcode, this chickenbit (specific to the Zen2 + uarch) disables Floating Point Mov-Elimination to mitigate the + issue. + / + val &= ~chickenbit; + if (sig->rev < goodrev) + val |= chickenbit;

This leaves me wondering: why have this line at all? I understand Xen wanting to enable the chicken bit on vulnerable CPUs, but why disable it on other AMD CPUs? If someone or something had enabled the bit, that's probably intentional, and even if not it probably shouldn't be Xen's business to alter CPU behavior beyond what's necessary for Xen itself to work reliably and securely.

Am I missing something? There is an earlier exit in this function for any non-Zen2 system.

So here, we are strictly on Zen2 (all vulnerable), and either have good microcode or not.

The microcode fix is far more performant than the chickenbit.

This chickenbit is something unrelated to FP move-elimination on other microarchitectures.

~Andrew

A division-by-zero error on some AMD processors can potentially return speculative data resulting in loss of confidentiality.

Last updated 25 April 2025

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

Xen Security Advisory CVE-2023-20569 / XSA-434

x86/AMD: Speculative Return Stack Overflow

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

Researchers from ETH Zurich have extended their prior research (XSA-422, Branch Type Confusion, a.k.a Retbleed) and have discovered INCEPTION, also know as RAS (Return Address Stack) Poisoning, and Speculative Return Stack Overflow.

The RAS is updated when a CALL instruction is predicted, rather than at a later point in the pipeline. However, the RAS is still fundamentally a circular stack.

It is possible to poison the branch type and target predictions such that, at a point of the attackers choosing, the branch predictor predicts enough CALLs back-to-back to wrap around the entire RAS and overwrite a correct return prediction with one of the attackers choosing.

This allows the attacker to control RET speculation in a victim context, and leak arbitrary data as a result.

For more details, see: https://comsec.ethz.ch/inception https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-7005

IMPACT ======

An attacker might be able to infer the contents of memory belonging to other guests.

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

Only CPUs from AMD are believed to be potentially vulnerable. CPUs from other manufacturers are not believed to be impacted.

At the time of writing, all in-support AMD CPUs (that is, Zen1 thru Zen4 microarchitectures) are believed to be potentially vulnerable. Older CPUs have not been analysed.

By default following XSA-422, Xen mitigates BTC on AMD Zen2 and older CPUs by issuing an IBPB on entry to Xen. On Zen2 and older CPUs, this is believed to be sufficient to protect against SRSO too.

AMD Zen3 and Zen4 CPUs are susceptible to SRSO too. All versions of Xen are vulnerable on these CPUs.

MITIGATION ==========

On Zen3 and Zen4, there is no mitigation.

RESOLUTION ==========

AMD are producing microcode updates for Zen3 and Zen4. Consult your dom0 OS vendor.

With the microcode update applied, booting Xen with spec-ctrl=ibpb-entry is sufficient to protect against SRSO.

The appropriate set of patches will default to using IBPB-on-entry on Zen3 and Zen4 CPUs, as well as synthesise new CPUID bits for guests to use in order to determine their susceptibility in a migration-safe way.

The patches for this issue interact texturally but not logically with the fixes for XSA-435, which itself has complexities. See XSA-435 for details of how to obtain the fixes. -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmTSZOsMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ8uMIAL2xBV/B3O0t90aFhX75dOWZBUkujMN0xHDjyI+c lnEmy44QnX+jI9IBSuc4qaJmLXnUO71WsMU1XeKucOnh9E1kjgHB2H0GgS+GI6dG LtAVxn+RRK39YIO0CHAXvr/tlX/eyodvxtmxOKLRY47J0hHLToXBEdc2VfXrUEfk 8AZn4hhHDGfRMX7jguxPFnrKCS3sZCFn1FYPtUxNGi2BbUzFacc+zZ2OISR7C59H 24q9UIgUVoVwOnUWBEzW6oHmjP44Q0kG3E8LhZQhr1YkAG++KapgTPllc3cU4xja G8ozTeMeyVbM29EMS7QknOlkvMSUmtgzNg7Pt6El9oSyuH4= =rrcN -----END PGP SIGNATURE-----

Mishandling of guest SSBD selection on AMD hardware The current logic to set SSBD on AMD Family 17h and Hygon Family 18h processors requires that the setting of SSBD is coordinated at a core level, as the setting is shared between threads. Logic was introduced to keep track of how many threads require SSBD active in order to coordinate it, such logic relies on using a per-core counter of threads that have SSBD active. When running on the mentioned hardware, it's possible for a guest to under or overflow the thread counter, because each write to VIRTSPECCTRL.SSBD by the guest gets propagated to the helper that does the per-core active accounting. Underflowing the counter causes the value to get saturated, and thus attempts for guests running on the same core to set SSBD won't have effect because the hypervisor assumes it's already active.

x86 shadow paging arbitrary pointer dereference In environments where host assisted address translation is necessary but Hardware Assisted Paging (HAP) is unavailable, Xen will run guests in so called shadow mode. Due to too lax a check in one of the hypervisor routines used for shadow page handling it is possible for a guest with a PCI device passed through to cause the hypervisor to access an arbitrary pointer partially under guest control.

x86: speculative vulnerability in 32bit SYSCALL path Due to an oversight in the very original Spectre/Meltdown security work (XSA-254), one entrypath performs its speculation-safety actions too late. In some configurations, there is an unprotected RET instruction which can be attacked with a variety of speculative attacks.

x86 shadow plus log-dirty mode use-after-free In environments where host assisted address translation is necessary but Hardware Assisted Paging (HAP) is unavailable, Xen will run guests in so called shadow mode. Shadow mode maintains a pool of memory used for both shadow page tables as well as auxiliary data structures. To migrate or snapshot guests, Xen additionally runs them in so called log-dirty mode. The data structures needed by the log-dirty tracking are part of aformentioned auxiliary data. In order to keep error handling efforts within reasonable bounds, for operations which may require memory allocations shadow mode logic ensures up front that enough memory is available for the worst case requirements. Unfortunately, while page table memory is properly accounted for on the code path requiring the potential establishing of new shadows, demands by the log-dirty infrastructure were not taken into consideration. As a result, just established shadow page tables could be freed again immediately, while other code is still accessing them on the assumption that they would remain allocated.

x86/HVM pinned cache attributes mis-handling T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] To allow cachability control for HVM guests with passed through devices, an interface exists to explicitly override defaults which would otherwise be put in place. While not exposed to the affected guests themselves, the interface specifically exists for domains controlling such guests. This interface may therefore be used by not fully privileged entities, e.g. qemu running deprivileged in Dom0 or qemu running in a so called stub-domain. With this exposure it is an issue that - the number of the such controlled regions was unbounded (CVE-2022-42333), - installation and removal of such regions was not properly serialized (CVE-2022-42334).

x86/HVM pinned cache attributes mis-handling T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] To allow cachability control for HVM guests with passed through devices, an interface exists to explicitly override defaults which would otherwise be put in place. While not exposed to the affected guests themselves, the interface specifically exists for domains controlling such guests. This interface may therefore be used by not fully privileged entities, e.g. qemu running deprivileged in Dom0 or qemu running in a so called stub-domain. With this exposure it is an issue that - the number of the such controlled regions was unbounded (CVE-2022-42333), - installation and removal of such regions was not properly serialized (CVE-2022-42334).

Guests can cause Xenstore crash via soft reset When a guest issues a "Soft Reset" (e.g. for performing a kexec) the libxl based Xen toolstack will normally perform a XSRELEASE Xenstore operation. Due to a bug in xenstored this can result in a crash of xenstored. Any other use of XSRELEASE will have the same impact.

IBPB may not prevent return branch predictions from being specified by pre-IBPB branch targets leading to a potential information disclosure.

Arm: unbounded memory consumption for 2nd-level page tables Certain actions require e.g. removing pages from a guest's P2M (Physical-to-Machine) mapping. When large pages are in use to map guest pages in the 2nd-stage page tables, such a removal operation may incur a memory allocation (to replace a large mapping with individual smaller ones). These memory allocations are taken from the global memory pool. A malicious guest might be able to cause the global memory pool to be exhausted by manipulating its own P2M mappings.

P2M pool freeing may take excessively long The P2M pool backing second level address translation for guests may be of significant size. Therefore its freeing may take more time than is reasonable without intermediate preemption checks. Such checking for the need to preempt was so far missing.

lock order inversion in transitive grant copy handling As part of XSA-226 a missing cleanup call was inserted on an error handling path. While doing so, locking requirements were not paid attention to. As a result two cooperating guests granting each other transitive grants can cause locks to be acquired nested within one another, but in respectively opposite order. With suitable timing between the involved grant copy operations this may result in the locking up of a CPU.

insufficient TLB flush for x86 PV guests in shadow mode For migration as well as to work around kernels unaware of L1TF (see XSA-273), PV guests may be run in shadow paging mode. To address XSA-401, code was moved inside a function in Xen. This code movement missed a variable changing meaning / value between old and new code positions. The now wrong use of the variable did lead to a wrong TLB flush condition, omitting flushes where such are necessary.