We have just published Qubes Security Bulletin (QSB) 082: Memory management issues in PV frontend drivers. The text of this QSB is reproduced below. This QSB and its accompanying signatures will always be available in the Qubes Security Pack (qubes-secpack).

View QSB-082 in the qubes-secpack:


In addition, you may wish to:

             ---===[ Qubes Security Bulletin 082 ]===---


           Memory management issues in PV frontend drivers

User action required

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

  For Qubes 4.0, in dom0:
  - Xen packages, version 4.8.5-42
  - Linux kernel packages (kernel*-qubes-vm), versions 5.4.203, 5.8.9,

  For Qubes 4.1, in dom0:
  - Xen packages, version 4.14.5-5
  - Linux kernel packages (kernel*-qubes-vm), versions 5.15.52, 5.8.9,

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. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]

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

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 and Linux binaries.


The following security advisories were published on 2022-07-05:

XSA-403 [3] "Linux disk/nic frontends data leaks":

| Linux Block and Network PV device frontends don't zero memory regions
| before sharing them with the backend.  Additionally the granularity of
| the grant table doesn't allow sharing less than a 4K page, leading to
| unrelated data residing in the same 4K page as data shared with a
| backend being accessible by such backend.
| An untrusted backend can access data not intended to be shared.  If
| such mappings are made with write permissions the backend could also
| cause malfunctions and/or crashes to consumers of contiguous data in
| the shared pages.

XSA-405 [4] "The PV network backend may cause Linux netfront to use
freed SKBs":

| While adding logic to support XDP (eXpress Data Path), a code label
| was moved in a way allowing for SKBs having references (pointers)
| retained for further processing to nevertheless be freed.
| A misbehaving or malicious backend may cause a Denial of Service (DoS)
| in the guest.  Information leaks or privilege escalation cannot be
| ruled out.


These vulnerabilities, if exploited, could allow a malicious VM that
serves as a network or a block backend to leak data from its frontend.
The ability to execute code in the frontend cannot be ruled out.

In the default Qubes OS configuration, this means that sys-net could
attack sys-firewall, and sys-firewall could attack qubes connected to
it. Furthermore, a qube to which a block device is assigned from an
untrusted backend qube can be attacked by that backend. (For example,
sys-usb could attack qubes to which a USB drive is attached as a block
device.) Qubes that do not have any NetVM set and to which no block
devices are assigned are not affected.


See the original Xen Security Advisory.


[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://xenbits.xen.org/xsa/advisory-403.html
[4] https://xenbits.xen.org/xsa/advisory-405.html

The Qubes Security Team