Fedora 34 approaching EOL; Fedora 35 templates available
https://www.qubes-os.org/news/2022/05/26/fedora-34-approaching-eol-fedora-35-templates-available/

Fedora 34 is scheduled to reach EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)) on 2022-06-07, and
new Fedora 35 templates are now available for both Qubes 4.0 and 4.1.

We strongly recommend that all Qubes users upgrade (https://www.qubes-os.org/doc/templates/fedora/#upgrading) their Fedora 34
templates and standalones to Fedora 35 before Fedora 34 reaches EOL.

We provide fresh Fedora 35 template packages through the official Qubes
repositories, which you can install in dom0 by following the standard
installation instructions (https://www.qubes-os.org/doc/templates/fedora/#installing). Alternatively, we also provide step-by-step
instructions for performing an in-place upgrade (https://www.qubes-os.org/doc/templates/fedora/) of an existing Fedora
template. After upgrading your templates, please remember to switch all
qubes that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).

For a complete list of template releases that are supported for your
specific Qubes release, see our supported template releases (https://www.qubes-os.org/doc/supported-releases/#templates).

Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL (https://www.qubes-os.org/doc/supported-releases/#note-on-dom0-and-eol).

Fedora 34 has reached EOL
https://www.qubes-os.org/news/2022/06/07/fedora-34-eol/

As a reminder following our previous announcement (https://www.qubes-os.org/news/2022/05/26/fedora-34-approaching-eol-fedora-35-templates-available/), Fedora 34 has now
reached EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)). If you have not already done so, we
strongly recommend upgrading (https://www.qubes-os.org/doc/templates/fedora/#upgrading) all remaining Fedora 34 templates and
standalones to Fedora 35 immediately.

We provide fresh Fedora 35 template packages through the official Qubes
repositories, which you can install in dom0 by following the standard
installation instructions (https://www.qubes-os.org/doc/templates/fedora/#installing). Alternatively, we also provide step-by-step
instructions for performing an in-place upgrade (https://www.qubes-os.org/doc/templates/fedora/in-place-upgrade/) of an existing Fedora
template. After upgrading your templates, please remember to switch all
qubes that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).

For a complete list of template releases that are supported for your
specific Qubes release, see our supported template releases (https://www.qubes-os.org/doc/supported-releases/#templates).

Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL (https://www.qubes-os.org/doc/supported-releases/#note-on-dom0-and-eol).

XSAs released on 2022-06-09
https://www.qubes-os.org/news/2022/06/09/xsas-released-on-2022-06-09/

The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is affected.
Therefore, user action is required.

XSAs that affect the security of Qubes OS (user action required)

The following XSAs do affect the security of Qubes OS:


XSA-401
XSA-402


Please see QSB-080 for the actions users must take in order to
protect themselves, as well as further details about these XSAs:

https://www.qubes-os.org/news/2022/06/09/qsb-080/

XSAs that do not affect the security of Qubes OS (no user action required)

The following XSAs do not affect the security of Qubes OS, and no user action is necessary:


(none)


Related links


Xen XSA list: https://xenbits.xen.org/xsa/
Qubes XSA tracker: https://www.qubes-os.org/security/xsa/
Qubes security pack (qubes-secpack): https://www.qubes-os.org/security/pack/
Qubes security bulletins (QSBs): https://www.qubes-os.org/security/qsb/

QSB-080: Issues with PV domains and PCI passthrough (XSA-401, XSA-402)
https://www.qubes-os.org/news/2022/06/09/qsb-080/

We have just published Qubes Security Bulletin (QSB) 080:
Issues with PV domains and PCI passthrough (XSA-401, XSA-402).
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-080 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-080-2022.txt

In addition, you may wish to:


Get the qubes-secpack: https://www.qubes-os.org/security/pack/
View all past QSBs: https://www.qubes-os.org/security/qsb/
View the XSA Tracker: https://www.qubes-os.org/security/xsa/



---===[ Qubes Security Bulletin 080 ]===---

2022-06-09

Issues with PV domains and PCI passthrough (XSA-401, XSA-402)


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

For Qubes 4.1, in dom0:
- Xen packages, version 4.14.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. [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
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.


Summary
--------

The following security advisories were published on 2022-06-09:

XSA-401 [3] "x86 pv: Race condition in typeref acquisition":

| Xen maintains a type reference count for pages, in addition to a
| regular reference count. This scheme is used to maintain invariants
| required for Xen's safety, e.g. PV guests may not have direct
| writeable access to pagetables; updates need auditing by Xen.
|
| Unfortunately, the logic for acquiring a type reference has a race
| condition, whereby a safely TLB flush is issued too early and creates
| a window where the guest can re-establish the read/write mapping
| before writeability is prohibited.

XSA-402 [4] "x86 pv: Insufficient care with non-coherent mappings":

| Xen maintains a type reference count for pages, in addition to a
| regular reference count. This scheme is used to maintain invariants
| required for Xen's safety, e.g. PV guests may not have direct
| writeable access to pagetables; updates need auditing by Xen.
|
| Unfortunately, Xen's safety logic doesn't account for CPU-induced
| cache non-coherency; cases where the CPU can cause the content of the
| cache to be different to the content in main memory. In such cases,
| Xen's safety logic can incorrectly conclude that the contents of a
| page is safe.


Impact
-------

These vulnerabilities, if exploited, could allow malicious PV domains
with assigned PCI devices to escalate their privileges to that of the
host. However, in the default Qubes OS configuration, these
vulnerabilities affect only the stubdomains for sys-net and sys-usb.
Therefore, in order to exploit these vulnerabilities in a default Qubes
installation, an adversary would first have to discover and exploit an
independent vulnerability in QEMU in order to gain control of an
appropriate stubdomain. Only after having done so would the adversary be
in a position to attempt to exploit the vulnerabilities discussed in
this bulletin.

XSA-402 affects only AMD systems and Intel systems before Ivy Bridge
(the third generation of the Intel Core processors). Newer Intel systems
are not affected.


Credits
--------

See the original Xen Security Advisory.


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

[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-401.html
[4] https://xenbits.xen.org/xsa/advisory-402.html

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

Qubes Canary 031
https://www.qubes-os.org/news/2022/06/12/canary-031/

We have published Qubes Canary 031. The text of this canary is
reproduced below.

This canary and its accompanying signatures will always be available in
the Qubes security pack (qubes-secpack).

View Qubes Canary 031 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-031-2022.txt

Learn how to obtain and authenticate the qubes-secpack and all the
signatures it contains:

https://www.qubes-os.org/security/pack/

View all past canaries:

https://www.qubes-os.org/security/canary/


---===[ Qubes Canary 031 ]===---


Statements
-----------

The Qubes security team members who have digitally signed this file [1]
state the following:

1. The date of issue of this canary is June 11, 2022.

2. There have been 80 Qubes security bulletins published so far.

3. The Qubes Master Signing Key fingerprint is:

427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494

4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).

5. We plan to publish the next of these canary statements in the first
fourteen days of September 2022. Special note should be taken if no new
canary is published by that time or if the list of statements changes
without plausible explanation.


Special announcements
----------------------

None.


Disclaimers and notes
----------------------

We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently compromised.
This means that we assume NO trust in any of the servers or services
which host or provide any Qubes-related data, in particular, software
updates, source code repositories, and Qubes ISO downloads.

This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other means,
like blackmail or compromising the signers' laptops, to coerce us to
produce false declarations.

The proof of freshness provided below serves to demonstrate that this
canary could not have been created prior to the date stated. It shows
that a series of canaries was not created in advance.

This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to anybody.
None of the signers should be ever held legally responsible for any of
the statements made here.


Proof of freshness
-------------------

Sat, 11 Jun 2022 16:02:15 +0000

Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
The Artillery War in the Donbas: Ukraine Relying Heavily on Heavy Weapons from the West
Ongoing Dependence on Russian Energy: The Natural Gas Continues to Flow
Europe's Top Prosecutor Brings In More Money than She Spends
The Courageous Women of Kabul: Standing Up to the Taliban's Burqa Decree
Kremlin Threats: Europe Has To Learn To Defend Itself, But How?

Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
‘We Buried Him and Kept Walking’: Children Die as Somalis Flee Hunger
Rumbling Through Modern Jordan, a Railway From the Past
McDonald’s Is Reinvented in Russia as the Economy Stumbles On
Newly United, French Left Hopes to Counter President in Upcoming Vote
Recording India’s Linguistic Riches as Leaders Push Hindi as Nation’s Tongue

Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Russia hands out passports in occupied Ukraine cities
Putin and Peter the Great: Russian leader likens himself to 18th Century tsar
China warns Taiwan independence would trigger war
Qatar World Cup 2022: German ex-football star says host's treatment of gay people is unacceptable
China: Footage of women attacked in restaurant sparks outrage

Source: Blockchain.info

000000000000000000032e9b82971c2ef2eb1362c65e01f1db5f60fa81fd5eef


Footnotes
----------

[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this canary
in the qubes-secpack.git repo, and (2) via digital signatures on the
corresponding qubes-secpack.git repo tags. [2]

[2] Don't just trust the contents of this file blindly! Verify the
digital signatures! Instructions for doing so are documented here:
https://www.qubes-os.org/security/pack/

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

QSB-081: x86: MMIO Stale Data vulnerabilities (XSA-404)
https://www.qubes-os.org/news/2022/06/17/qsb-081/

We have just published Qubes Security Bulletin (QSB) 081:
x86: MMIO Stale Data vulnerabilities (XSA-404).
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-081 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-081-2022.txt

In addition, you may wish to:


Get the qubes-secpack: https://www.qubes-os.org/security/pack/
View all past QSBs: https://www.qubes-os.org/security/qsb/
View the XSA Tracker: https://www.qubes-os.org/security/xsa/



---===[ Qubes Security Bulletin 081 ]===---

2022-06-17

x86: MMIO Stale Data vulnerabilities (XSA-404)


User action required
---------------------

Users with appropriate hardware (see the "affected hardware" section
below) 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-41

For Qubes 4.1, in dom0:
- Xen packages, version 4.14.5-3

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


Summary
--------

On 2022-06-14, the Xen Project published XSA-404, "x86: MMIO Stale
Data vulnerabilities" [3]:

| This issue is related to the SRBDS, TAA and MDS vulnerabilities.
| Please see:
|
| https://xenbits.xen.org/xsa/advisory-320.html (SRBDS)
| https://xenbits.xen.org/xsa/advisory-305.html (TAA)
| https://xenbits.xen.org/xsa/advisory-297.html (MDS)
|
| Please see Intel's whitepaper:
|
| https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/processor-mmio-stale-data-vulnerabilities.html


Impact
-------

An adversary who controls a VM with an assigned PCI device can infer
the memory content of other guests or Xen itself. This could allow the
adversary to read information that should be accessible only to Xen or
another VM and to use that information to launch further attacks. In
the default Qubes OS configuration, only sys-net and sys-usb can be
used to perform this attack.


Affected hardware
------------------

All Intel systems are affected. While mitigations are available, they
are available only for some Intel CPU models. Normally, it should be a
simple matter to look up a given CPU model number in a table to see
whether it is affected and whether it is eligible for any mitigations.
Indeed, Intel has published a table [4] that claims to serve this
purpose. Unfortunately, however, we have found several inaccuracies in
this table. Since we cannot rely on the table, we have had to devise an
alternative method using other published Intel technical documents that
appear to be more accurate. This has turned out to be quite complex.

Our best evidence indicates that mitigations are available for all and
only those CPUs that are both eligible for and updated with the Intel
microcode update released in May 2022. [5] Since going through all the
complicated technical steps of checking this manually would be
excessively cumbersome for most users, we have written a tool that does
it for you. Please note that this tool is entirely optional and is *not*
required for any security updates to take effect. Rather, its intended
purpose is to satisfy the curiosity of users who wish to know whether
their own CPUs are eligible for mitigations and who would struggle to

make that determination manually. This tool is included in the
`qubes-core-dom0-linux-4.0.35` package for Qubes 4.0 and the
`qubes-core-dom0-linux-4.1.23` package for Qubes 4.1. 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]

After installing the required updates, you will be able to execute `sudo
cpu-microcode-info` in a dom0 terminal. This will output a table of
information about the logical CPUs (aka CPU "cores") in your system. The
"F-M-S/PI" column lists the "Family-Model-Stepping/Platform ID" codes
that Intel uses in its microcode documentation, [5] which is explained
in further detail in Intel's README. [6] (The manual process of checking
would involve extracting your CPU information, converting it to
hexadecimal, and looking it up in the appropriate table in this
document.) The "Loaded microcode version" column lists the microcode
versions currently loaded for each CPU. The "20220510 update available"
column lists whether the required May 2022 microcode update is
*available* for each CPU. The "20220510 update installed" column lists
whether the required May 2022 microcode update is *installed* in each
CPU.

In order for the updates associated with this bulletin to successfully
mitigate XSA-404, a value of "yes" is required in both of these last two
"20220510 update" columns. If the "available" column has a "yes" while
the "installed" column has a "no," then the May 2022 microcode update
must be installed first. If both columns have "no" values, then this CPU
remains vulnerable, and there is no known mitigation available. If your
system has such a CPU, then installing The Xen packages listed in the
"user action required" section above is *not* expected to mitigate the
problem described in this bulletin. Unfortunately, there is simply
nothing we can do for these CPUs in terms of patching unless we receive
a fix from Intel or receive new information about which CPUs are
affected. Nonetheless, we still recommend installing the updates anyway
(once available), since they will not make the problem any worse,
keeping up-to-date with all security updates is a general best practice,
and future updates will be based on the latest version.

However, hope is not entirely lost for users whose CPUs are not eligible
for software mitigations. Since the vulnerability discussed in this
bulletin does not affect VMs without PCI passthrough devices, users
still have the option of altering their habits to treat VMs like sys-usb
and sys-net as more trusted. While this can be especially challenging in
the case of sys-net, it at least affords users *some* latitude in
working around the problem by being mindful of when such VMs are
running, how trusted their templates are, and similar considerations.


Further plans regarding PCI passthrough
----------------------------------------

This is yet another issue affecting only VMs with access to PCI devices.
This pattern of vulnerabilities has prompted us to research more secure
ways of handling such VMs in future Qubes releases. Eventually, we plan
to treat them as more privileged VMs that require additional protection.
Specific protective measures will be discussed with the community as
part of our ongoing research and development efforts.


Credits
--------

See the original Xen Security Advisory.


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

[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-404.html
[4] https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
[5] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md#microcode-20220510

[6] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files#about-processor-signature-family-model-stepping-and-platform-id


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

Qubes OS 4.1.1-rc1 has been released!
https://www.qubes-os.org/news/2022/06/27/qubes-4-1-1-rc1/

We’re pleased to announce the first release candidate for Qubes 4.1.1!
This release aims to consolidate all the security patches, bug fixes,
and upstream template OS upgrades that have occurred since the initial
Qubes 4.1.0 release in February. Our goal is to provide a secure and
convenient way for users to install (or reinstall) the latest stable
Qubes release with an up-to-date ISO.

Qubes 4.1.1-rc1 is available on the downloads (https://www.qubes-os.org/downloads/) page.

What is a release candidate?

A release candidate (RC) is a software build that has the potential to
become a stable release, unless significant bugs are discovered in
testing. Release candidates are intended for more advanced (or
adventurous!) users who are comfortable testing early versions of
software that are potentially buggier than stable releases. You can read
more about the Qubes OS release process in the version scheme (https://www.qubes-os.org/doc/version-scheme/)
documentation.

What is a patch release?

The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version
numbers are written as ... Hence, we refer to
releases that increment the third number as “patch releases.” A patch
release does not designate a separate, new major or minor release of
Qubes OS. Rather, it designates its respective major or minor release
(in this case, 4.1.0) inclusive of all updates up to a certain point.
Installing Qubes 4.1.0 and fully updating it results in essentially the
same system as installing Qubes 4.1.1. You can learn more about how
Qubes release versioning works in the version scheme (https://www.qubes-os.org/doc/version-scheme/) documentation.

What’s new in Qubes 4.1.1?

Qubes 4.1.1-rc1 includes numerous updates over the initial 4.1.0
release, in particular:


All 4.1.0 dom0 updates to date
Fedora 36 template (upgraded from Fedora 34)
Linux kernel 5.15 (upgraded from 5.10)


How to test Qubes 4.1.1-rc1

If you’re willing to test (https://www.qubes-os.org/doc/testing/) this release candidate, you can help to
improve the eventual stable release by reporting any bugs you
encounter (https://www.qubes-os.org/doc/issue-tracking/). We strongly encourage experience users to join the testing
team (https://forum.qubes-os.org/t/joining-the-testing-team/5190)!

Release candidate planning

If no significant bugs are discovered in 4.1.1-rc1, we expect to
announce the stable release of 4.1.1 in two to three weeks.

Qubes OS 4.0 reaches EOL on 2022-08-04
https://www.qubes-os.org/news/2022/07/04/qubes-os-4-0-eol-on-2022-08-04/

Qubes OS 4.0 is scheduled to reach end-of-life (EOL) on 2022-08-04 — one
month from the date of this announcement.

What about patch releases?

The Qubes OS Project uses the semantic versioning (https://semver.org/)
standard. Version numbers are written as ... When a
major or minor release reaches EOL, all of its patch releases also reach EOL.
For example, in this case, when we say that “Qubes 4.0” (without specifying a
number) is approaching EOL, we’re specifying a particular minor
release, inclusive of all patch releases within it. This means that Qubes
4.0.0, 4.0.1, 4.0.2, 4.0.3, and 4.0.4 will all reach EOL at the same time (on
2022-08-04), since they are all just patch releases of the same minor release.

How are EOL dates determined?

According to our support policy (https://www.qubes-os.org/doc/supported-releases/), stable Qubes OS
releases are supported for six months after each subsequent major or minor
release (https://www.qubes-os.org/doc/version-scheme/). This means that Qubes 4.0 reaches EOL six
months after Qubes 4.1 was released. Since Qubes 4.1.0 was released on
2022-02-04 (https://www.qubes-os.org/news/2022/02/04/qubes-4-1-0/), Qubes 4.0’s EOL date is six months
later, on 2022-08-04.

Fun fact: Qubes 4.0.0 was initially released on
2018-03-28 (https://www.qubes-os.org/news/2018/03/28/qubes-40/), which means that it will be four
years, four months, and one week old when it reaches EOL. That’s the longest
support period for a stable Qubes release in our project’s history!

What should I do?

First off, if you’re already using Qubes 4.1, then you don’t have to do
anything. This announcement doesn’t affect you.

However, if you’ve stood by the venerable Qubes 4.0 till now, then you’ll want
to make sure you upgrade to Qubes 4.1 by 2022-08-04. When you upgrade,
though, depends on a few factors. You have several options (in no particular
order):



Perform an in-place upgrade (https://www.qubes-os.org/doc/upgrade/4.1/#in-place-upgrade) any time
between now and 2022-08-04.


Perform a clean install now using the stable Qubes 4.1.0
ISO (https://www.qubes-os.org/downloads/#qubes-release-4-1-0), which was published on
2022-02-04 (https://www.qubes-os.org/news/2022/02/04/qubes-4-1-0/).


Perform a clean install now using the first release candidate for Qubes
4.1.1 (https://www.qubes-os.org/news/2022/06/27/qubes-4-1-1-rc1/).


Wait to see whether the stable Qubes 4.1.1 ISO is published within the next
month.



Allow me to explain what I mean by the last option: While we certainly hope
to be able to announce the stable 4.1.1 release within the next few weeks, we
cannot guarantee that outcome. After all, the entire point of having release
candidates is because sometimes major bugs are discovered in builds that were
thought to be nearly ready for release. While we don’t expect any, we can never
be certain that no such bug will be found.

So, for those looking for a clean installation option, the main advantage of
the existing 4.1.0 ISO is that it is already available right now, while
there’s a decent chance but no guarantee that the stable 4.1.1 ISO will be
ready in time. Meanwhile, the release candidate is intended for testers and
adventurous types who don’t mind a bit of risk. The release candidates are not
intended for cases in which system reliability is required for important work.

The main disadvantage of the existing 4.1.0 ISO is that it’s quite old by
now. It’s missing some security updates (which you should download immediately
after installing, if you choose to go that route) and comes with an old Fedora
template that has already reached EOL (which you should upgrade immediately
after installing or refrain from using in favor of other templates).

If you’re not in any particular hurry to upgrade (and, if you’ve been content

to stick with 4.0 until now, then you’re probably not), one strategy is simply
to wait until closer to the EOL date, and see whether the stable 4.1.1 ISO
arrives in time. If it does, great! You can preform a clean install using that.
If it doesn’t, then you haven’t lost anything. You still have the same choices
you have right now. Just make sure you to leave yourself enough time to upgrade
one way or another!

XSAs released on 2022-07-05
https://www.qubes-os.org/news/2022/07/05/xsas-released-on-2022-07-05/

The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is affected.
Therefore, user action is required.

XSAs that affect the security of Qubes OS (user action required)

The following XSAs do affect the security of Qubes OS:


XSA-403
XSA-405


Please see QSB-082 for the actions users must take in order to
protect themselves, as well as further details about these XSAs:

https://www.qubes-os.org/news/2022/07/05/qsb-082/

XSAs that do not affect the security of Qubes OS (no user action required)

The following XSAs do not affect the security of Qubes OS, and no user action is necessary:


XSA-406 (ARM architecture only)


Related links


Xen XSA list: https://xenbits.xen.org/xsa/
Qubes XSA tracker: https://www.qubes-os.org/security/xsa/
Qubes security pack (qubes-secpack): https://www.qubes-os.org/security/pack/
Qubes security bulletins (QSBs): https://www.qubes-os.org/security/qsb/

QSB-082: Memory management issues in PV frontend drivers
https://www.qubes-os.org/news/2022/07/05/qsb-082/

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:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-082-2022.txt

In addition, you may wish to:


Get the qubes-secpack: https://www.qubes-os.org/security/pack/
View all past QSBs: https://www.qubes-os.org/security/qsb/
View the XSA Tracker: https://www.qubes-os.org/security/xsa/



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

2022-07-05

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

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

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


Summary
--------

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.


Impact
-------

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.


Credits
--------

See the original Xen Security Advisory.


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

[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
https://www.qubes-os.org/security/

XSAs released on 2022-07-12
https://www.qubes-os.org/news/2022/07/13/xsas-released-on-2022-07-12/

The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is affected.
Therefore, user action is required.

XSAs that affect the security of Qubes OS (user action required)

The following XSAs do affect the security of Qubes OS:


XSA-407


Please see QSB-083 for the actions users must take in order to
protect themselves, as well as further details about these XSAs:

https://www.qubes-os.org/news/2022/07/13/qsb-083/

XSAs that do not affect the security of Qubes OS (no user action required)

The following XSAs do not affect the security of Qubes OS, and no user action is necessary:


(none)


Related links


Xen XSA list: https://xenbits.xen.org/xsa/
Qubes XSA tracker: https://www.qubes-os.org/security/xsa/
Qubes security pack (qubes-secpack): https://www.qubes-os.org/security/pack/
Qubes security bulletins (QSBs): https://www.qubes-os.org/security/qsb/

QSB-083: Retbleed: Arbitrary speculative code execution with return instructions (XSA-407)
https://www.qubes-os.org/news/2022/07/13/qsb-083/

We have just published Qubes Security Bulletin (QSB) 083: Retbleed:
Arbitrary speculative code execution with return instructions (XSA-407).
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-083 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-083-2022.txt

In addition, you may wish to:


Get the qubes-secpack: https://www.qubes-os.org/security/pack/
View all past QSBs: https://www.qubes-os.org/security/qsb/
View the XSA Tracker: https://www.qubes-os.org/security/xsa/



---===[ Qubes Security Bulletin 083 ]===---

2022-07-12

Retbleed

Arbitrary speculative code execution
with return instructions (XSA-407)


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

For Qubes 4.1, in dom0:
- Xen packages, version 4.14.5-6

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


Summary
--------

On 2022-07-12, the Xen Project published XSA-407, "Retbleed -
arbitrary speculative code execution with return instructions" [3]:

| Researchers at ETH Zurich have discovered Retbleed, allowing for
| arbitrary speculative execution in a victim context.
|
| For more details, see:
| https://comsec.ethz.ch/retbleed
|
| ETH Zurich have allocated CVE-2022-29900 for AMD and CVE-2022-29901 for
| Intel.
|
| Despite the similar preconditions, these are very different
| microarchitectural behaviours between vendors.
|
| On AMD CPUs, Retbleed is one specific instance of a more general
| microarchitectural behaviour called Branch Type Confusion. AMD have
| assigned CVE-2022-23816 (Retbleed) and CVE-2022-23825 (Branch Type
| Confusion).
|
| For more details, see:
| https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1037
|
| On Intel CPUs, Retbleed is not a new vulnerability; it is only
| applicable to software which did not follow Intel's original
| Spectre-v2 guidance. Intel are using the ETH Zurich allocated
| CVE-2022-29901.
|
| For more details, see:
| https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00702.html
| https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html
|
| ARM have indicated existing guidance on Spectre-v2 is sufficient.


Impact
-------

This is yet another speculative execution issue, which allows an
attacker to infer content of memory they shouldn't have access to. This
includes one VM extracting secrets from another. Any VM can perform this
attack on an affected hardware.

AMD systems based on Zen 1 - Zen 2 microarchitectures are affected.
Specifically those are AMD Ryzen processors with model names 1xxx - 4xxx
and some 5xxxU [4]. Zen 3 microarchitecture (AMD Ryzen 5xxx or newer)
are not affected.

Pre-existing Xen mitigations on Intel machines are effective to prevent
this issue, so Intel systems are not affected.

Credits
--------

See the original Xen Security Advisory.


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

[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-407.html
[4] Unlike other 5xxxU models, Ryzen 3 5300U, Ryzen 5 5500U and
Ryzen 7 5700U are Zen 2, not Zen 3. See
https://en.wikipedia.org/wiki/Zen2
https://en.wikipedia.org/wiki/Zen3

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