Qubes OS 69 Published by

Qubes Security Bulletin 116 addresses four new Xen vulnerabilities (XSA-500, XSA-505, XSA-506, and XSA-507) that could allow malicious virtual machines to compromise system memory or leak sensitive data across isolated qubes. While the default Qubes OS configuration faces moderate risk, administrators running paravirtualized workloads, untrusted HVM qubes, or templates with active memory balancing should treat these flaws as high priority. Systems operating on Qubes OS 4.3 can resolve the issues by upgrading dom0 to Xen package version 4.19.5-2 through the standard update tool and then rebooting the machine. Anyone who previously enabled Anti Evil Maid protection must also reseal their secret passphrase, since the updated binaries shift PCR values 18 and 19.

QSB-116: Multiple Xen issues (XSA-500, XSA-505, XSA-506, XSA-507)




QSB-116: Multiple Xen issues (XSA-500, XSA-505, XSA-506, XSA-507)


We have published Qubes Security Bulletin (QSB) 116: Multiple Xen issues (XSA-500, XSA-505, XSA-506, XSA-507). The text of this QSB and its accompanying cryptographic signatures are reproduced below, followed by a general explanation of this announcement and authentication instructions.

Qubes Security Bulletin 116


---===[ Qubes Security Bulletin 116 ]===---

2026-07-28

Multiple Xen issues (XSA-500, XSA-505, XSA-506, XSA-507)

User action
------------

Continue to update normally [1] in order to receive the security updates
described in the "Patching" section below. No other user action is
required in response to this QSB.

Summary
--------

On 2026-07-28, the Xen Project published the security advisories below.

XSA-500 [3] "grant-table: type confusion in grant-copy":

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


XSA-505 [4] "evtchn: Race between FIFO expand and reset":

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


XSA-506 [5] "correct buffer checks for DM_OP hypercalls":

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

XSA-507 [6] "PoD: Don't try to reclaim special pages":

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

Impact
-------

XSA-500 and XSA-507: A malicious qube may be able to compromise
Qubes OS.

XSA-505: A malicious PV qube [7] may be able to compromise Qubes OS. The
same impact applies to stubdomains for HVM qubes [8], but in this case
an attacker would first have to discover and exploit an independent
vulnerability (in QEMU) in order to gain access to the stubdomain.

XSA-506: The stubdomain for an HVM qube may be able to leak data from
other qubes in the system. In order to exploit this vulnerability, an
attacker would first have to discover and exploit an independent
vulnerability (in QEMU) in order to gain access to the stubdomain.

Affected systems
-----------------

XSA-500: All systems are affected.

XSA-505: Systems with either PV qubes or stubdomains for HVM qubes (or
both) are affected, but the vulnerability is easier to exploit on
systems with PV qubes. In the default Qubes OS configuration, there are
no PV qubes, but sys-net and sys-usb are HVM qubes that have
stubdomains. This means that the vulnerability is more difficult to
exploit in the default Qubes OS configuration, but if a user has
manually created PV qubes in a particular system, the vulnerability will
be easier to exploit on that system.

XSA-506: Systems with untrusted HVM qubes are affected. In the default
configuration of Qubes OS, sys-net and sys-usb are HVM qubes and are
considered to be untrusted.

XSA-507: Systems are affected if they have qubes that are included in
memory balancing but that don't advertise memory hotplug support. This
includes malicious HVM qubes with memory balancing enabled, as well as
templates and standalones that use in-qube kernels and that have memory
balancing enabled. The default Qubes OS configuration is not affected,
nor are commonly-used HVM qubes like Windows, since they don't have
memory balancing enabled.

Patching
---------

The following packages contain security updates that address the
vulnerabilities described in this bulletin:

For Qubes 4.3, in dom0:
- Xen packages, version 4.19.5-2

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [2] Once available, the packages should be installed
via the Qubes Update tool or its command-line equivalents. [1]

Dom0 must be restarted afterward in order for the updates to take
effect.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new Xen
binaries.

Credits
--------

See the original Xen Security Advisories. [3][4][5][6]

References
-----------

[1] https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to-update.html
[2] https://doc.qubes-os.org/en/latest/user/downloading-installing-upgrading/testing.html
[3] https://xenbits.xen.org/xsa/advisory-500.html
[4] https://xenbits.xen.org/xsa/advisory-505.html
[5] https://xenbits.xen.org/xsa/advisory-506.html
[6] https://xenbits.xen.org/xsa/advisory-507.html
[7] A PV qube is a qube that is running with virt_mode set to "pv."
[8] For each qube that is running with virt_mode set to "hvm," there's a
small Xen-internal helper VM running alongside it, in which QEMU is
executed to provide device emulation for that qube. This helper VM
runs in PV mode and is called a "stubdomain."

The Qubes Security Team
https://www.qubes-os.org/security/

Source: qsb-116-2026.txt

Marek Marczykowski-Górecki’s PGP signature