Xen Security Advisory CVE-2026-23553 / XSA-479
x86: incomplete IBPB for vCPU isolation
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.
Guest processes may leverage information leaks to obtain information
intended to be private to other entities in a guest.
Xen versions which had the XSA-254 fixes backported are vulnerable.
Upstream, that is 4.6 and newer.
Only x86 systems are vulnerable. Arm systems are not vulerable.
Systems vulnerable to SRSO (see XSA-434) with default settings use
IBPB-on-entry to protect against SRSO. This is a rather more aggressive
form of flushing than only on context switch, and is believed to be
sufficient to avoid the vulnerability.
Using "spec-ctrl=ibpb-entry=hvm,ibpb-entry=pv" on the Xen command line
will activate the SRSO mitigation on non-SRSO-vulnerable hardware, but
it is a large overhead.
This issue was discovered by David Kaplan of AMD.
https://xenbits.xenproject.org/xsa/advisory-479.html
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
Xen Security Advisory CVE-2025-58150 / XSA-477
x86: buffer overrun with shadow paging + tracing
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.
The exact effects depend on what's adjacent to the variables in
question. The most likely effects are bogus trace data, but none of
privilege escalation, information leaks, or Denial of Service (DoS) can
be excluded without detailed analysis of the particular build of Xen.
Only x86 systems are vulnerable. Arm systems are not vulnerable.
Only HVM guests running in shadow paging mode and with tracing enabled
can leverage the vulnerability.
Running HVM guests in HAP mode only will avoid the vulnerability.
Not enabling tracing will also avoid the vulnerability. Tracing is
enabled by the "tbuf_size=" command line option, or by running tools
like xentrace or xenbaked in Dom0. Note that on a running system
stopping xentrace / xenbaked would disable tracing. For xentrace,
however, this additionally requires that it wasn't started with the -x
option. Stopping previously enabled tracing can of course only prevent
future damage; prior damage may have occurred and may manifest only
later.
This issue was discovered by Jan Beulich of SUSE.
https://xenbits.xenproject.org/xsa/advisory-477.html
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
Follow-up to d151f99d0f
Compute the `$out/usr/lib` target using `hostPlatform.is64bit` and
`is32bit` instead of explicitly listing supported systems.
Note: `hostPlatform.libDir` is not used because it doesn't handle
non-linux systems and does not match the FHS expectations for aarch64 in
this context.
R. Ryantm