Xen Security Advisory 462 v2 (CVE-2024-45817) - x86: Deadlock in vlapic_error()

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2024-45817 / XSA-462
   version 2

x86: Deadlock in vlapic_error()

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

In x86's APIC (Advanced Programmable Interrupt Controller) architecture,
error conditions are reported in a status register.  Furthermore, the OS
can opt to receive an interrupt when a new error occurs.

It is possible to configure the error interrupt with an illegal vector,
which generates an error when an error interrupt is raised.

This case causes Xen to recurse through vlapic_error().  The recursion
itself is bounded; errors accumulate in the the status register and only
generate an interrupt when a new status bit becomes set.

However, the lock protecting this state in Xen will try to be taken
recursively, and deadlock.

IMPACT
==

A buggy or malicious HVM or PVH guest can deadlock Xen, leading to a
DoS.

VULNERABLE SYSTEMS
==

Xen 4.5 and onwards are vulnerable.  Xen 4.4 and older are not vulnerable.

Only x86 systems running HVM or PVH guests are vulnerable.
Architectures other than x86 are not vulnerable.

Only HVM or PVH guests can leverage the vulnerability.  PV guests cannot
leverage the vulnerability.

MITIGATION
==

Not running untrusted HVM or PVH VMs will avoid this vulnerability.

CREDITS
===

This issue was discovered after a BUGSENG team working on MISRA C
compliance of Xen pointed attention to ECLAIR reports for MISRA C Rule
17.2 (Functions shall not call themselves, either directly or
indirectly).

RESOLUTION
==

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

xsa462.patch   xen-unstable - Xen 4.16.x

$ sha256sum xsa462*
c8cb03fdcfffa7e043b1d82643efde0f93bff5ce484887c6f5920ee95be7  xsa462.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/4UyVfoK9kFAmbymG8MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ+MYIALQiqD84Ryme+mKRunKqDuH3P3pTX9bvxFp8sRZd
B0A3ysBKsC+eSJHsuH+vaTPG25e72+cqSs1Wr1PHs+p99UA4QxG8vT8pbAIAyr3f
lHVJvHfqMYA3xxNwS82us2Hjiv0t4spBBDje9TgcRvJf8nAcrPrQ+k6eycTTTGiz
kMT5pjkaiKTf0+uZ13krzHHCTyDwYKYJJly0FOv4TbNH+Bxj0i7b630BUtxGibMT
Cm5ay+CK3QSIJUGG6OjSAfFQWxZJ0W7gg1RNsH/ExsvsMw9sE2mX0YbHKaYD6yWf
wEmwQvAwYeaa91fcRnkr9dTZMYy5ObeUQLqJz1EJJ1indyU=
=dr22
-END PGP SIGNATURE-


xsa462.patch
Description: Binary data

Xen Security Advisory 461 v2 (CVE-2024-31146) - PCI device pass-through with shared resources

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2024-31146 / XSA-461
   version 2

 PCI device pass-through with shared resources

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

When multiple devices share resources and one of them is to be passed
through to a guest, security of the entire system and of respective
guests individually cannot really be guaranteed without knowing
internals of any of the involved guests.  Therefore such a configuration
cannot really be security-supported, yet making that explicit was so far
missing.

Resources the sharing of which is known to be problematic include, but
are not limited to
- - PCI Base Address Registers (BARs) of multiple devices mapping to the
  same page (4k on x86),
- - INTx lines.

IMPACT
==

The precise effects when shared resources are in use are system, device,
guest, and resource specific.  None of privilege escalation, information
leaks, or Denial of Service (DoS) can be ruled out.

VULNERABLE SYSTEMS
==

All systems making use of PCI pass-through are in principle vulnerable,
when any kind of resource is shared.  Just to re-iterate, even in the
absence of resource sharing caveats apply to passing through of PCI
devices to entirely untrusted guests.

MITIGATION
==

Passing through only SR-IOV virtual functions or devices with well-
separated resources will avoid this particular vulnerability.  Passing
through all devices sharing a given resource to the same guest will also
avoid this particular vulnerability.

RESOLUTION
==

Applying the appropriate attached patch documents 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.

xsa461.patch   xen-unstable - Xen 4.16.x

$ sha256sum xsa461*
2415504496508ad87c306aa7257e836d7c2f0bd8849656de5b586f0ab93fd17f  xsa461.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of patches or mitigations is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List).  Specifically, deployment on public cloud systems
is NOT permitted.

This is because changing the nature of devices being passed through is
very likely noticeable by the guest.

Deployment is permitted only AFTER the embargo ends.

(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/4UyVfoK9kFAma8sCkMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZLDkH/i6esACkik7iglEESFgCj0x6fc3KdpVzsCPznmsn
uWZzBO9xuggoPOONJ70Or7tsIdaYDAkealZrBGreXlPEgd0MOtozLYrvB2IIqJEj
cKyC4Y04VpBkynaOiLraFvUs0xyC0cew1NZdE/cxr9ewRvvrHVcyBI5GBAMKworh
g4hjIDOR9ohhvxN2P7Yz59OY+Ojo57t+IlpvPPm+c53bARYR6H/cxyUDLYVlfrk2
iNPif7Wpi1PU/Sjz5XqBF5mXW+LLsLnbyw8Iyhnjqv1zC/tUdzl1INUBd24eHSjP
aXnrlExoGAuvUcf/6YVfU0u2dB7iISGYAs2ESeYuxpJnZ8E=
=LkWz
-END PGP SIGNATURE-


xsa461.patch
Description: Binary data

Xen Security Advisory 460 v2 (CVE-2024-31145) - error handling in x86 IOMMU identity mapping

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2024-31145 / XSA-460
   version 2

 error handling in x86 IOMMU identity mapping

UPDATES IN VERSION 2


Wording updated. Public release.

ISSUE DESCRIPTION
=

Certain PCI devices in a system might be assigned Reserved Memory
Regions (specified via Reserved Memory Region Reporting, "RMRR") for
Intel VT-d or Unity Mapping ranges for AMD-Vi.  These are typically used
for platform tasks such as legacy USB emulation.

Since the precise purpose of these regions is unknown, once a device
associated with such a region is active, the mappings of these regions
need to remain continuouly accessible by the device.  In the logic
establishing these mappings, error handling was flawed, resulting in
such mappings to potentially remain in place when they should have been
removed again.  Respective guests would then gain access to memory
regions which they aren't supposed to have access to.

IMPACT
==

The precise impact is system specific.  Denial of Service (DoS)
affecting the entire host or individual guests, privilege escalation,
and information leaks cannot be ruled out.

VULNERABLE SYSTEMS
==

Only x86 systems passing PCI devices with RMRR/Unity regions through to
guests are potentially affected.

PCI devices listed in a vm.cfg file have error handling which causes `xl
create` to abort and tear down the domain, and is thus believed to be
safe.

PCI devices attached using `xl pci-attach` will result in the command
returning nonzero, but will not tear down the domain.  VMs which
continue to run after `xl pci-attach` has failed expose the
vulnerability.

For x86 Intel hardware, Xen versions 4.0 and later are affected.

For all x86 hardware, Xen versions having the XSA-378 fixes applied /
backported are affected.

MITIGATION
==

Assigning devices using the vm.cfg file for attachment at boot avoids
the vulnerability.

CREDITS
===

This issue was discovered by Teddy Astie of Vates and diagnosed as a
security issue by Jan Beulich of SUSE.

RESOLUTION
==

Applying the 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 respective stable branch before applying these patches.

xsa460.patch   xen-unstable - Xen 4.16.x

$ sha256sum xsa460*
f4ca598f71e9ef6b9bc50803df2996b92d2e69afd8e36d9544823d7e56ec1819  xsa460.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/4UyVfoK9kFAma8sCIMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZiSUIAMFWxhjNzhsuUGbrUVsO6oDIs7gOcVEsC3BlcsIp
LqetutOWHwR8B9jHeOjewZjgL/q1031qX+nCCcU/ilZtA7cAiVhPNrh4PSD/D9S5
RqUG3oSsFjSTtGwVl2JlqlHoE90tXOqLBhZFCJixQzaW3kbCfhDZdmufj8TQYBCQ
N3ioNAGwvmSeV8QPh8l3P7TRRsMwr0OTWQYtj7r4QuW+dDPJaKzbCpmWVaCPVeI2
uKUxwwIxSE9J9L1mUR34HIJR/clCFNqlcpc/MmQVz0qprBOh4jNDunN+JNDY1VXR
3P+N50ZnHCK5w1z+vjeVvZRyp9JDt2LDUj6XJ6G9IdvN1xA=
=vNzh
-END PGP SIGNATURE-


xsa460.patch
Description: Binary data

Xen Security Advisory 458 v2 (CVE-2024-31143) - double unlock in x86 guest IRQ handling

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2024-31143 / XSA-458
   version 2

double unlock in x86 guest IRQ handling

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

An optional feature of PCI MSI called "Multiple Message" allows a
device to use multiple consecutive interrupt vectors.  Unlike for MSI-X,
the setting up of these consecutive vectors needs to happen all in one
go.  In this handling an error path could be taken in different
situations, with or without a particular lock held.  This error path
wrongly releases the lock even when it is not currently held.

IMPACT
==

Denial of Service (DoS) affecting the entire host, crashes, information
leaks, or elevation of privilege all cannot be ruled out.

VULNERABLE SYSTEMS
==

Xen versions 4.4 and newer are vulnerable.  Xen versions 4.3 and older
are not vulnerable.

Only x86 guest which have a multi-vector MSI capable device passed
through to them can leverage the vulnerability.

MITIGATION
==

Not passing through multi-vector MSI capable devices to x86 guests will
avoid the vulnerability.

CREDITS
===

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==

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

xsa458.patch   xen-unstable - Xen 4.16.x

$ sha256sum xsa458*
22dd1071755b1fd6b4ea3ce18a200f626ee796e77b7e7d93a3a5b33d2a896706  xsa458.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patch described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.

HOWEVER, deployment of the mitigation is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List).  Specifically, deployment on public cloud systems
is NOT permitted.

This is because removing/replacing of pass-through devices or their
replacement by emulated devices is a guest visible configuration
change, which may lead to re-discovery of the issue.

Deployment of this mitigation is permitted only AFTER the embargo ends.

AND: 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/4UyVfoK9kFAmaWYKoMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZKLgH/1uXqtha34XUX2xCayPYMss6yIwXDuugw4Z/F8Ap
tb+p65idTw5s2X0BXLpCcvhBZNY151DQXi0BZhTMewO8+JxrdjKPLthNSkGtF+/W
issUCQ9cuSj84n7n5AeMq1WDqVBYMnqNlgrsv9oiKAQ5g+9Rf8Mpu7RG1NrNcTCs
CfeDgMTOQcBuYG2xW2+46SXHVXKLA28uq6w4nIns4JpPF63DUJQKDDdypky1CSf1
9Z81Axi3cpk3NPvTw7TW2csO1C04XBVJvVVHJtUF1FVUhe0NboQy/zbh2te3QdJ8
KPXsQ55p0AZm3x8K2qM+Lsm1DqYhG5/ORMGC/+bXWc2H/nU=
=ZqmX
-END PGP SIGNATURE-


xsa458.patch
Description: Binary data

Xen Security Advisory 459 v2 (CVE-2024-31144) - Xapi: Metadata injection attack against backup/restore functionality

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2024-31144 / XSA-459
   version 2

  Xapi: Metadata injection attack against backup/restore functionality

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

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.

IMPACT
==

If a fraudulent metadata backup has been written into an SR which also
contains a legitimate metadata backup, and an administrator explicitly
chooses to restore from backup, the fraudulent metadata might be
consumed instead of the legitimate metadata.

Control over meta data includes: which VMs are created, disk assignment,
vCPU/RAM requirements, GPU allocation, etc.

VULNERABLE SYSTEMS
==

Systems running Xapi v1.249.x are affected.

Systems running Xapi v24.x are potentially affected.  However it is
believed that the only supported products using this version of Xapi
have not shipped the metadata backup/restore functionality.

To leverage the vulnerability, an attacker would likely need insider
information to construct a plausible-looking metadata backup, and would
have to persuade a real administrator to perform a data-recovery action.

MITIGATION
==

Not using the metadata restore functionality avoids the vulnerability.

CREDITS
===

This issue was discovered by XenServer.

RESOLUTION
==

The attached patches resolve the issue for Xapi v1.249.x releases.

xsa459-xen-api.patch (based on v1.249.37) causes all new metadata VDIs
to be created with a deterministic UUID, and restore functionality to use
that UUID only; not to search all disks to find the metadata.

After installing the updated Xapi, a new metadata backup should be
taken, to create a VDI with the new deterministic UUID.

The ability to restore from an old backup VDI is retained, but the
administrator is required to specify the exact VDI to use, so as to
avoid searching the SR.

Because xsa459-xen-api.patch alters the behaviour of the
xe-{backup,restore}-metadata scripts, a companion patch
xsa459-xsconsole.patch (based on v10.1.13.1) is needed to keep the
pre-existing menu options working, and to ask for user conformation if
needing to restore from a prior backup.

Note: some work was carried out in public on this issue before the
security implications were understood.  These changes are present in
xen-api.git and tagged as v1.249.37, which is used as the base for this
patch.

$ sha256sum xsa459*
89dba36a1889a41fbf585a25432079d10991d9e9f3c2d9f93f285c11e17e02c3  
xsa459-xen-api.patch
0fc4dabd3a84055644fe415f55d8a1148ad2c17aaa2f8b52889cb11800c612d2  
xsa459-xsconsole.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-

iQFABAEBC

Xen Security Advisory 457 v3 (CVE-2024-27393) - Linux/xen-netfront: Memory leak due to missing cleanup function

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2024-27393 / XSA-457
  version 3

Linux/xen-netfront: Memory leak due to missing cleanup function

UPDATES IN VERSION 3


CVE assigned.

ISSUE DESCRIPTION
=

In netfront, xennet_alloc_one_rx_buffer() failed to call the
appropriate clean-up function, resulting in a memory leak.

IMPACT
==

A malicious guest userspace process can exhaust memory resources
within the guest kernel, potentially leading to a guest crash (Denial
of Service). It is not known whether it can be triggered remotely.

VULNERABLE SYSTEMS
==

Systems with guests running Linux 5.9 and later with Xen PV network
devices are affected.

MITIGATION
==

For HVM guests, using emulated network devices will avoid this issue.

RESOLUTION
==

The following patch in Linux resolves the issue:

https://git.kernel.org/torvalds/c/037965402a010898d34f4e35327d22c0a95cd51f

A copy of which is attached.

xsa457.patch   Linux 5.9

$ sha256sum xsa457*
9d6ae3da27f1ff92f9f45c800822beecda603d6dea6726207cee6c768416114c  xsa457.patch
$


NOTE ON THE LACK OF EMBARGO
===

The issue was reported initially on a public bug tracker and fixed in
public before it was realized that there was a security aspect.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmY7+mgMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZIygH/2qlkovJs5zZy4dTpsygoSnSiv6L31r2IGmMnR/c
qdgtfedzctQ/ibw0iaz/37w/d0F3lo/lg3iWnVgCcIfV384MvvoArFsOZ4v/RRXL
b0XiNCb0k5xLpw9R86f7oG7cDw59JU+sXVjBH6GcVo86yL+HKaeli7/FZb9zkz/D
VRushpxeA353u3FFdqHJcFlD68wA5nhM2JdjkPk1rrgPVc0sBLjHwrcFOrHHHuuq
epYSYzWEf5HGbOf+zg6NY9B0uD4Vb9J3xa+xcYaHfPlQ1Jexw5GA7vBMO82qcR57
lRwAOav844fHw+lNxizfg8+4ayFpOCyGX2WEag6qjN92qJE=
=mMwm
-END PGP SIGNATURE-


xsa457.patch
Description: Binary data

Xen Security Advisory 457 v2 - Linux/xen-netfront: Memory leak due to missing cleanup function

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-457
  version 2

Linux/xen-netfront: Memory leak due to missing cleanup function

UPDATES IN VERSION 2


* Clarify the XSA is in netfront and *not* netback
* Clarify the impact: only the guest may crash

ISSUE DESCRIPTION
=

In netfront, xennet_alloc_one_rx_buffer() failed to call the
appropriate clean-up function, resulting in a memory leak.

IMPACT
==

A malicious guest userspace process can exhaust memory resources
within the guest kernel, potentially leading to a guest crash (Denial
of Service). It is not known whether it can be triggered remotely.

VULNERABLE SYSTEMS
==

Systems with guests running Linux 5.9 and later with Xen PV network
devices are affected.

MITIGATION
==

For HVM guests, using emulated network devices will avoid this issue.

RESOLUTION
==

The following patch in Linux resolves the issue:

https://git.kernel.org/torvalds/c/037965402a010898d34f4e35327d22c0a95cd51f

A copy of which is attached.

xsa457.patch   Linux 5.9

$ sha256sum xsa457*
9d6ae3da27f1ff92f9f45c800822beecda603d6dea6726207cee6c768416114c  xsa457.patch
$


NOTE ON THE LACK OF EMBARGO
===

The issue was reported initially on a public bug tracker and fixed in
public before it was realized that there was a security aspect.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmY7W/gMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZnPQIAIPhOEXsSKutZJF776KKDmoNDmZ00SikkfZ9tZW8
LyiNNJ7l7tDN3A5EVJn4l8Xos+PFaadNIXdaLKemRt17nP4Qw+UzjvBTiTbou+m7
OGUGsRMCNkfpv8OEi/U91o3W3uEE/tL7ahws/wAnOzEfcbTFl5alTDfuDfrtOaiA
1Uz37QO0GNQSD+n91SyosqAljfbAvWNQMLJ+Iz9YB6BonVwsWWNeHjF1N9zDWv3k
pD+DVOa60FYIA3xxeJveZO3ZLA6oBo5wyKiQ8p3bun9X9W5+i6PrzWewnsWCvya+
Yyi0xTZ2YBzo+eNFpQ9OKqjDVoSREx9l9Ef0YvSStR0/aBw=
=/9cg
-END PGP SIGNATURE-


xsa457.patch
Description: Binary data

Xen Security Advisory 457 v1 - Linux/xen-netback: Memory leak due to missing cleanup function

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-457

Linux/xen-netback: Memory leak due to missing cleanup function

ISSUE DESCRIPTION
=

In netback, xennet_alloc_one_rx_buffer() failed to call the
appropriate clean-up function, resulting in a memory leak.

IMPACT
==

A malicious guest userspace process can exhaust memory resources
within the guest kernel, potentially leading to a system crash (Denial
of Service). It is not known whether it can be triggered remotely.

VULNERABLE SYSTEMS
==

Systems with guests running Linux 5.9 and later with Xen PV network
devices are affected.

MITIGATION
==

For HVM guests, using emulated network devices will avoid this issue.

RESOLUTION
==

The following patch in Linux resolves the issue:

https://git.kernel.org/torvalds/c/037965402a010898d34f4e35327d22c0a95cd51f

A copy of which has attached.

xsa457.patch   Linux 5.9

$ sha256sum xsa457*
9d6ae3da27f1ff92f9f45c800822beecda603d6dea6726207cee6c768416114c  xsa457.patch
$


NOTE ON THE LACK OF EMBARGO
===

The issue was reported initially on a public bug tracker and fixed in
public before it was realized that there was a security aspect.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmY6YN8MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZq4kH/0BcaF/4dKqxQ/hYMMoLxcE1kzHn2kAdFPcvxcuu
Csk1yLugbvxHgwgp0lI9JjiqzSMt68pN8B9mWbcMBBvA7jGGsJ6Vjp25kQnUToLe
FPiAhW/TY+1YXOnhsfn9dHHk1Tv0W5D69QuUuj6zGUvRMdV+WPyA/mGPWnBrJgT+
5s6tKFxls1JiLdFxuJKqi8Ok8HrX1zE9unSWEUri8SNE2k3h5i29X2v+S8yBv2y0
XBnzr16kL9KKim0sNSErB1QU5BThnDBCFk+7FKAAYGAv5H6N3VLv66DLARCYfPhP
iXJU3/+yvAjwZjp5oYtbqHXzdd/m0b/IrF/0ZMLBaoDs0s4=
=vfs6
-END PGP SIGNATURE-


xsa457.patch
Description: Binary data

Xen Security Advisory 456 v3 (CVE-2024-2201) - x86: Native Branch History Injection

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2024-2201 / XSA-456
  version 3

 x86: Native Branch History Injection

UPDATES IN VERSION 3


Issues were found with the original code changes.  See the bottom of the
Resolution section for how to obtain those.

ISSUE DESCRIPTION
=

In August 2022, researchers at VU Amsterdam disclosed Spectre-BHB.

Spectre-BHB was discussed in XSA-398.  At the time, the susceptibility
of Xen to Spectre-BHB was uncertain so no specific action was taken in
XSA-398.  However, various changes were made thereafter in upstream Xen
as a consequence; more on these later.

VU Amsterdam have subsequently adjusted the attack to be pulled off
entirely from userspace, without the aid of a managed runtime in the
victim context.

For more details, see:
  https://vusec.net/projects/native-bhi
  https://vusec.net/projects/bhi-spectre-bhb
  
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html
  https://xenbits.xen.org/xsa/advisory-398.html

IMPACT
==

An attacker might be able to infer the contents of arbitrary host
memory, including memory assigned to other guests.

VULNERABLE SYSTEMS
==

Systems running all versions of Xen are affected.

Only Intel x86 CPUs are potentially affected.  CPUs from other
manufacturers are not known to be affected.

A wide range of Intel CPUs employ Branch History prediction techniques.
However for older CPUs existing Spectre-v2 mitigations (XSA-254) are
believed to be sufficient to mitigate Native-BHI.

Therefore, the rest of the discussion will be limited in scope to the
CPUs for which a change in behaviour is expected.  These are believed to
be all CPUs with eIBRS (Enhanced IBRS, a.k.a. IBRS_ALL or IBRS_ATT).
eIBRS signifies a hardware adjustment (mode-tagged indirect predictions)
designed to combat Spectre-v2, available in CPUs from 2019 onwards.

To determine if a system has eIBRS, run `xen-cpuid -v` in dom0, looking for
the string "eibrs" in the Dynamic Raw block of information.  e.g.

  # xen-cpuid -v
  ...
  Dynamic sets:
  Raw ...
...
[16] MSR_ARCH_CAPS.lo ... eibrs ...
...
  ...

Be aware that the Static sets are compile time information so will include the
string "eibrs" irrespective of hardware support.  If there is no row for "[16]
MSR_ARCH_CAPS.lo" then the fixes for XSA-435 are missing.

MITIGATION
==

There are no mitigations.

CREDITS
===

This issue was discovered by VU Amsterdam.

RESOLUTION
==

In Xen 4.17, in response to the original Spectre-BHB, CET-IBT support was
added to Xen to use on capable hardware.  It also came with work to remove
unnecessary function pointers, and to de-virtualise function pointers at boot,
as both a performance and hardening improvement.  This work has been steadily
continuing since, and every removed/de-virtualised function pointer reduces
the options available to an adversary trying to mount a Native-BHI attack.
All of this work has been backported to 4.17 and later for this advisory.

Beginning with the Intel Alder Lake (Client) and Sapphire Rapids (Server)
CPUs, a hardware control called BHI_DIS_S is available, which restricts
history-based predictions.  This control requires updated microcode on some
CPUs.  Look for "bhi-ctrl" in `xen-cpuid -v`, similar to eibrs above.

Xen has been updated to use this control when available, and to virtualise it
for guests to use.

For CPUs without BHI_DIS_S, BHB clearing sequences need using.  Out of an
abundance of caution, all sequences in the Intel whitepaper have been
implemented, although Xen will only use the "short" sequence by default.  The
others are available to opt in to.

The work to mitigate Native-BHI is extensive, and the backports are
more-extensive still.

Therefore, we have decided to produce new releases on all stable trees.
Please find fixes in the respective branches under the following release
tags:

  RELEASE-4.18.2
  RELEASE-4.17.4
  RELEASE-4.16.6
  RELEASE-4.15.6

Other release activities (tarballs, announcements, etc) will happen in
due course.

Issues were in those found subsequently.  To address those, newer commits
from the stable branches need updating to, in particular

stable-4.15 05653eb44314cb90f2e3e7b2d405e86b5657
stable-4.16 d0e8f8ffbb19b5df5f767328baeb54c069b08e6a
stable-4.17 effcf70f020ff12d34c80e2abde0ecb00ce92bda
stable-4.18 f0ff1d9cb96041a84a24857a6464628240deed4f

For 4.15, since we're closing the branch, RELEASE-4.15.7 was tagged in
addition; other release activities - as per above - will follow.

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 syste

Xen Security Advisory 456 v2 (CVE-2024-2201) - x86: Native Branch History Injection

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2024-2201 / XSA-456
  version 2

 x86: Native Branch History Injection

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

In August 2022, researchers at VU Amsterdam disclosed Spectre-BHB.

Spectre-BHB was discussed in XSA-398.  At the time, the susceptibility
of Xen to Spectre-BHB was uncertain so no specific action was taken in
XSA-398.  However, various changes were made thereafter in upstream Xen
as a consequence; more on these later.

VU Amsterdam have subsequently adjusted the attack to be pulled off
entirely from userspace, without the aid of a managed runtime in the
victim context.

For more details, see:
  https://vusec.net/projects/native-bhi
  https://vusec.net/projects/bhi-spectre-bhb
  
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html
  https://xenbits.xen.org/xsa/advisory-398.html

IMPACT
==

An attacker might be able to infer the contents of arbitrary host
memory, including memory assigned to other guests.

VULNERABLE SYSTEMS
==

Systems running all versions of Xen are affected.

Only Intel x86 CPUs are potentially affected.  CPUs from other
manufacturers are not known to be affected.

A wide range of Intel CPUs employ Branch History prediction techniques.
However for older CPUs existing Spectre-v2 mitigations (XSA-254) are
believed to be sufficient to mitigate Native-BHI.

Therefore, the rest of the discussion will be limited in scope to the
CPUs for which a change in behaviour is expected.  These are believed to
be all CPUs with eIBRS (Enhanced IBRS, a.k.a. IBRS_ALL or IBRS_ATT).
eIBRS signifies a hardware adjustment (mode-tagged indirect predictions)
designed to combat Spectre-v2, available in CPUs from 2019 onwards.

To determine if a system has eIBRS, run `xen-cpuid -v` in dom0, looking for
the string "eibrs" in the Dynamic Raw block of information.  e.g.

  # xen-cpuid -v
  ...
  Dynamic sets:
  Raw ...
...
[16] MSR_ARCH_CAPS.lo ... eibrs ...
...
  ...

Be aware that the Static sets are compile time information so will include the
string "eibrs" irrespective of hardware support.  If there is no row for "[16]
MSR_ARCH_CAPS.lo" then the fixes for XSA-435 are missing.

MITIGATION
==

There are no mitigations.

CREDITS
===

This issue was discovered by VU Amsterdam.

RESOLUTION
==

In Xen 4.17, in response to the original Spectre-BHB, CET-IBT support was
added to Xen to use on capable hardware.  It also came with work to remove
unnecessary function pointers, and to de-virtualise function pointers at boot,
as both a performance and hardening improvement.  This work has been steadily
continuing since, and every removed/de-virtualised function pointer reduces
the options available to an adversary trying to mount a Native-BHI attack.
All of this work has been backported to 4.17 and later for this advisory.

Beginning with the Intel Alder Lake (Client) and Sapphire Rapids (Server)
CPUs, a hardware control called BHI_DIS_S is available, which restricts
history-based predictions.  This control requires updated microcode on some
CPUs.  Look for "bhi-ctrl" in `xen-cpuid -v`, similar to eibrs above.

Xen has been updated to use this control when available, and to virtualise it
for guests to use.

For CPUs without BHI_DIS_S, BHB clearing sequences need using.  Out of an
abundance of caution, all sequences in the Intel whitepaper have been
implemented, although Xen will only use the "short" sequence by default.  The
others are available to opt in to.

The work to mitigate Native-BHI is extensive, and the backports are
more-extensive still.

Therefore, we have decided to produce new releases on all stable trees.
Please find fixes in the respective branches under the following release
tags:

  RELEASE-4.18.2
  RELEASE-4.17.4
  RELEASE-4.16.6
  RELEASE-4.15.6

Other release activities (tarballs, announcements, etc) will happen in
due course.

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 permis

Xen Security Advisory 455 v4 (CVE-2024-31142) - x86: Incorrect logic for BTC/SRSO mitigations

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory CVE-2024-31142 / XSA-455
version 4

 x86: Incorrect logic for BTC/SRSO mitigations

UPDATES IN VERSION 4


Public release.

Correct references to prior XSAs.  The XSA fixing Branch Type Confusion
was XSA-407, not XSA-422 as previously stated.

ISSUE DESCRIPTION
=

Because of a logical error in XSA-407 (Branch Type Confusion), the
mitigation is not applied properly when it is intended to be used.
XSA-434 (Speculative Return Stack Overflow) uses the same
infrastructure, so is equally impacted.

For more details, see:
  https://xenbits.xen.org/xsa/advisory-407.html
  https://xenbits.xen.org/xsa/advisory-434.html

IMPACT
==

XSAs 407 and 434 are unmitigated, even when the patches are in place.

VULNERABLE SYSTEMS
==

All versions of Xen containing the XSA-407 fixes are vulnerable.

See XSAs 407 and 434 for details on which hardware is susceptible to
BTC/SRSO.

MITIGATION
==

There are no mitigations.

CREDITS
===

This issue was discovered by Andrew Cooper of XenServer.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

Note that the Xen Security Team is intending to produce releases on all
stable trees, on the public embargo.  Therefore, this fix is expected to
be contained in the following release tags:

  RELEASE-4.18.2
  RELEASE-4.17.4
  RELEASE-4.16.6
  RELEASE-4.15.6

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.

xsa455.patch   xen-unstable - Xen 4.17.x
xsa455-4.16.patch  Xen 4.16.x - Xen 4.15.x

$ sha256sum xsa455*
96bcfcc0ce1afcc54f637c728ab5250c65f0a5a1d8ccfc59ac5d496baf1a53a4  xsa455.patch
02e3fe13ac68f665534fabae1520254d5d1832fef7c95fceb190be3b9944a5e1  
xsa455-4.16.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.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmYVbQcMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZsY4IAJnYJTEEzhdG9+Qy/gcgwiKFB6lA5D6hQ1kAD739
fOh4GyA0ZYRLpfw8J4sVgYmPKl+S0Rx1qdt9X2GHVNIq5FqtFytx3lQt1VF4BTW6
kRHqqccHLKIo0MCRcNBw9wtn5BSQXpmJO9jpsazrBwxMPZpf2Z4mQhMO0aRxq2k7
Oyxz2O1ElNXzItuXM4ZT4OSR2pISjLC5mhKcauH3m/ecAbUwqEf6CjpvLXt7iI/0
OUqnZ7gO4m8fPoIaA0iT51o5Pb/EXTLnvyIrnlOL5C+xyNB8pQETP+cJZSnYYYWX
eNwQ+LwEgSHptPP09cbNFOnf+r1eJR22haPL2sMPveGbKRY=
=LR1k
-END PGP SIGNATURE-


xsa455.patch
Description: Binary data


xsa455-4.16.patch
Description: Binary data

Xen Security Advisory 454 v2 (CVE-2023-46842) - x86 HVM hypercalls may trigger Xen bug check

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-46842 / XSA-454
   version 2

 x86 HVM hypercalls may trigger Xen bug check

UPDATES IN VERSION 2


Avoid new Misra violation in 1st staging patch.

Public release.

ISSUE DESCRIPTION
=

Unlike 32-bit PV guests, HVM guests may switch freely between 64-bit and
other modes.  This in particular means that they may set registers used
to pass 32-bit-mode hypercall arguments to values outside of the range
32-bit code would be able to set them to.

When processing of hypercalls takes a considerable amount of time,
the hypervisor may choose to invoke a hypercall continuation.  Doing so
involves putting (perhaps updated) hypercall arguments in respective
registers.  For guests not running in 64-bit mode this further involves
a certain amount of translation of the values.

Unfortunately internal sanity checking of these translated values
assumes high halves of registers to always be clear when invoking a
hypercall.  When this is found not to be the case, it triggers a
consistency check in the hypervisor and causes a crash.

IMPACT
==

A HVM or PVH guest can cause a hypervisor crash, causing a Denial of
Service (DoS) of the entire host.

VULNERABLE SYSTEMS
==

All Xen versions from at least 3.2 onwards are vulnerable.  Earlier
versions have not been inspected.

Only x86 systems are vulnerable.  Arm systems are not vulnerable.

Only HVM or PVH guests can leverage the vulnerability.  PV guests cannot
leverage the vulnerability.

MITIGATION
==

Not using HVM / PVH guests will avoid the vulnerability.

CREDITS
===

This issue was discovered by Manuel Andreas of Technical University of
Munich.

RESOLUTION
==

Applying either of the attached patches from the appropriate set 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.

xsa454-?.patch   xen-unstable
xsa454-4.18-?.patch  Xen 4.18.x
xsa454-4.17-?.patch  Xen 4.17.x
xsa454-4.16-?.patch  Xen 4.16.x - Xen 4.15.x

$ sha256sum xsa454*
2df9af16605b634d3585a30f673b4cf9e327889cfd8714a697de215c3f809fb5  xsa454-1.patch
f2ed0468350f2c2e0285a546ab5c722e928add5425b05bff663c632ada09ee3b  xsa454-2.patch
4106f323251e262d30319c61de7c876f2b18edfcce38cc70501fb3c22677ff0a  
xsa454-4.16-1.patch
962ea7d8f3e378ec775619e44525f66768369423b56113420763651dbbf6bc1e  
xsa454-4.16-2.patch
95b299237d13ae27f643d804eb40b600b9b8ef056953686d4f770f03c46c42c8  
xsa454-4.17-1.patch
7af290595cbea3153e49344827095c874e6a8d208d8c843e62ee0787b0d7d46d  
xsa454-4.17-2.patch
999006e7917c996741dfc332d28e7b2ca8376f8e9d5b38161cbd5988528d0238  
xsa454-4.18-1.patch
f2ed0468350f2c2e0285a546ab5c722e928add5425b05bff663c632ada09ee3b  
xsa454-4.18-2.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/4UyVfoK9kFAmYVK4QMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZGckH/3BlZCckKISpUFMM/633xyAdJ8ZMVwZDhS2/eC+n
SJA4VuqAgw6dqqvAA5ga7jzBiCxe78S1BVXAZjOctmfVHRTOoyKg2hcEcKAit8uf
Pbxm/XHqgQRb6FTAlZROqX0rxq+7kSftm0teQWvMfauwVia59Shhye67dmdk9tCP
G8BTDFVEAspFYopQOiTmFQbxIkLLC6rg0UljQfxStPMw3MyX8pO5Lzl3+POlM1xV
XBynHxVmpdXNe1rFYcRKIsQWbbgYiEMXjQmOkax2mTfMHDhMZjkxvpLZa2jMfzkP
wTdqwWqO+z2eGZPWVL95uwZ49Q6Pzhnd6MXkn0wfHtDzy24=
=oUIS
-END PGP SIGNATURE-


xsa454-1.patch
Description: Binary data


xsa454-2.patch
Description: Binary data


xsa454-4.16-1.patch
Description: Binary data


xsa454-4.16-2.patch
Description: Binary data


xsa454-4.17-1.patch
Description: Binary data


xsa454-4.17-2.patch
Description: Binary data


xsa454-4.18-1.patch
Description: Binary data


xsa454-4.18-2.patch
Description: Binary data

Xen Security Advisory 451 v2 (CVE-2023-46841) - x86: shadow stack vs exceptions from emulation stubs

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-46841 / XSA-451
   version 2

 x86: shadow stack vs exceptions from emulation stubs

UPDATES IN VERSION 2


Largely cosmetic adjustment in patches.

Public release.

ISSUE DESCRIPTION
=

Recent x86 CPUs offer functionality named Control-flow Enforcement
Technology (CET).  A sub-feature of this are Shadow Stacks (CET-SS).
CET-SS is a hardware feature designed to protect against Return Oriented
Programming attacks. When enabled, traditional stacks holding both data
and return addresses are accompanied by so called "shadow stacks",
holding little more than return addresses.  Shadow stacks aren't
writable by normal instructions, and upon function returns their
contents are used to check for possible manipulation of a return address
coming from the traditional stack.

In particular certain memory accesses need intercepting by Xen.  In
various cases the necessary emulation involves kind of replaying of
the instruction.  Such replaying typically involves filling and then
invoking of a stub.  Such a replayed instruction may raise an
exceptions, which is expected and dealt with accordingly.

Unfortunately the interaction of both of the above wasn't right:
Recovery involves removal of a call frame from the (traditional) stack.
The counterpart of this operation for the shadow stack was missing.

IMPACT
==

An unprivileged guest can cause a hypervisor crash, causing a Denial of
Service (DoS) of the entire host.

VULNERABLE SYSTEMS
==

Xen 4.14 and onwards are vulnerable.  Xen 4.13 and older are not
vulnerable.

Only x86 systems with CET-SS enabled are vulnerable.  x86 systems with
CET-SS unavailable or disabled are not vulnerable.  Arm systems are not
vulnerable.  See
https://xenbits.xen.org/docs/latest/faq.html#tell-if-cet-is-active
for how to determine whether CET-SS is active.

Only HVM or PVH guests can leverage the vulnerability.  PV guests cannot
leverage the vulnerability.

MITIGATION
==

While in principle it is possible to disable use of CET on capable
systems using the "cet=no-shstk" command line option, doing so disables
an important security feature and may therefore not be advisable.

CREDITS
===

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==

Applying the appropriate (set of) attached patch(es) 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.

xsa451-?.patch xen-unstable
xsa451-4.18.patch  Xen 4.18.x
xsa451-4.17.patch  Xen 4.17.x
xsa451-4.16.patch  Xen 4.16.x
xsa451-4.15.patch  Xen 4.15.x

$ sha256sum xsa451*
446178a9a37646e62622988efffa3d1ffa0b579fc089ab79138507acfd3440c0  xsa451-1.patch
614ab6925ea60f36212f0cd01929f3a97161de1828040770792e146c170bfea2  xsa451-2.patch
ad529273d7dc97bff239f1727a9702eb24d41b723d2a3077a1fecc4684900f91  xsa451-3.patch
2c68480657220cfab92fe9821ce201ff7c9e0b541619a1add541f3d66fa13e9d  
xsa451-4.15.patch
fa8ab72e61fae0130fb81b0a7ce508fdb3bcb3c800b0ab7684aa6595cbad88ea  
xsa451-4.16.patch
e41cab6471586a5f50e10eb26895fec624cc6d8fd3b4ff71495466df8aaa19e5  
xsa451-4.17.patch
d6b76a8db6c80c0684fc94becc2e23091c8f1dcbebc726438dbb1a6cde543335  
xsa451-4.18.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/4UyVfoK9kFAmXdu4UMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZApoIAMmKsIAqbt/QlUZFUXYx+DAW20Bl7DUGjJlFv6kx
pBDSxW3a2evYo+CTTapVeRfosI+/kI61pcyFd19EGdthVcgufPQOC7yVxmu8j7Wi
s6lb/h0b6vKFOUubKN+EtaVRR34acqmQwSq668AjcyL8M5xIdWfYDpKHVft29x8i
QwKdKnvsWwaFrUathVTlspqcHLkNWf7+nsTVapMG2O15UrqYdJPErhL/Bh+iwSih
exc/fRFyQuqFL7qHnvPXz+AhajjHmDO+1Z3OCir9MleyZ3JJvIq6Vnje75+DFHeT
n9kFt29LJMvRzlDzIdfUy9R98h0r3WIQBaicFO2pBKlp6i8=
=JJb5
-END PGP SIGNATURE-


xsa451-1.p

Xen Security Advisory 449 v2 (CVE-2023-46839) - pci: phantom functions assigned to incorrect contexts

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-46839 / XSA-449
   version 2

 pci: phantom functions assigned to incorrect contexts

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

PCI devices can make use of a functionality called phantom functions,
that when enabled allows the device to generate requests using the IDs
of functions that are otherwise unpopulated.  This allows a device to
extend the number of outstanding requests.

Such phantom functions need an IOMMU context setup, but failure to
setup the context is not fatal when the device is assigned.  Not
failing device assignment when such failure happens can lead to the
primary device being assigned to a guest, while some of the phantom
functions are assigned to a different domain.

IMPACT
==

Under certain circumstances a malicious guest assigned a PCI device
with phantom functions may be able to access memory from a previous
owner of the device.

VULNERABLE SYSTEMS
==

Systems running all version of Xen are affected.

Only x86 systems are vulnerable.  Arm systems are not vulnerable.

Only systems using PCI passthrough of devices with phantom functions
are affected.

MITIGATION
==

There is no mitigation (other than not passing through PCI devices
with phantom functions to guests).

CREDITS
===

This issue was discovered by Roger Pau Monné of XenServer.

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.

xsa449.patch   xen-unstable - Xen 4.17.x
xsa449-4.16.patch  Xen 4.16.x - Xen 4.15.x

$ sha256sum xsa449*
f77914aae8f917952f66d863d26314875ff96a0d8178f64c94b95825eabbc8a8  xsa449.patch
8f0302c24535ad4c7379469f33afcfdce08ba6db970e0ca1a1bfdd788af6fc6c  
xsa449-4.16.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.

HOWEVER, deployment of the mitigation is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List).  Specifically, deployment on public cloud systems
is NOT permitted.

This is because removing/replacing of pass-through devices or their
replacement by emulated devices is a guest visible configuration
change, which may lead to re-discovery of the issue.

Deployment of this mitigation is permitted only AFTER the embargo ends.

AND: 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/4UyVfoK9kFAmW49O0MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZqVQH/jvY8MptcxkihMhykNkRON6H5aBaY0UQKzbiCVBy
Q0g6FoE59mHIsoIYvPHFFw0BNbxgubWkJRgowRTtwxKay9HWUKo22eKaLpX9I+TX
LUo7KFE02/MRWus6mjGNdaTghC2SzGghqAcwhQcPzuaE1qS31S/iWXTe9u0hITHv
M/zswSWuZK0UaejBy55hd/+L554yZ976coSFGyjqqIuSHvkR6+NFCzTSLp3GHsue
5CI3ouW0fR2aQ/Gu3pXBPgG464rQ9rQptsFW11uZ1Ahw9T4ZYQis9cRNNsM5I+f8
paGiJO2+y9oYoMkKRrkHXVwkhmZJbFzvpq0e4VkgHwZxbIc=
=L484
-END PGP SIGNATURE-


xsa449.patch
Description: Binary data


xsa449-4.16.patch
Description: Binary data

Xen Security Advisory 450 v2 (CVE-2023-46840) - VT-d: Failure to quarantine devices in !HVM builds

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-46840 / XSA-450
   version 2

   VT-d: Failure to quarantine devices in !HVM builds

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

Incorrect placement of a preprocessor directive in source code results
in logic that doesn't operate as intended when support for HVM guests is
compiled out of Xen.

IMPACT
==

When a device is removed from a domain, it is not properly quarantined
and retains its access to the domain to which it was previously
assigned.

VULNERABLE SYSTEMS
==

Xen 4.17 and onwards are vulnerable.  Xen 4.16 and older are not
vulnerable.

Only Xen running on x86 platforms with an Intel-compatible VT-d IOMMU is
vulnerable.  Platforms from other manufacturers, or platforms without a
VT-d IOMMU are not vulnerable.

Only systems where PCI devices are passed through to untrusted or
semi-trusted guests are vulnerable.  Systems which do not assign PCI
devices to untrusted guests are not vulnerable.

Xen is only vulnerable when CONFIG_HVM is disabled at build time.  Most
deployments of Xen are expected to have CONFIG_HVM enabled at build
time, and would therefore not be vulnerable.

MITIGATION
==

There is no mitigation.

CREDITS
===

This issue was discovered by Teddy Astie of Vates

RESOLUTION
==

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

xsa450.patch   xen-unstable - Xen 4.17.x

$ sha256sum xsa450*
738c79b92ab5ea57f446df3daff6564727fea5feebf8fadeb32acd0cf06ff9fb  xsa450.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/4UyVfoK9kFAmW49MwMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZnwcIALs07CQFYSuQmdgWRYeepkjehMSVhPhvJcYBCFWU
p+80oreGP2pC1LN+T9ndN0kDeUHAO8PeT+XqxHSNfT16Q5EOSeLpUQ8m+UfHUFLU
vtPMjR4sMpnvuZfx0OCMJctDDTM+/muw4AH0BO2zxFfDzGkM96zZ6vAokeer+5HQ
/P9usMm/6jphixVq919RBJ78fFZxKpKhil9tEwNuD6HJW3VNMWp1ypGNyFI3iRhw
XpYzWMB0eW6B6rSInohHJiTS7P6KE5zeXeBPZ5yVHy2J3e3c7nXyrQaaONSRCBdm
/Px2xcg1SpH+3UwoT56Z7tj1DhlgjcY4peb5B58oDK68hMU=
=Dp+G
-END PGP SIGNATURE-


xsa450.patch
Description: Binary data

Xen Security Advisory 448 v2 (CVE-2023-46838) - Linux: netback processing of zero-length transmit fragment

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-46838 / XSA-448
   version 2

  Linux: netback processing of zero-length transmit fragment

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

Transmit requests in Xen's virtual network protocol can consist of
multiple parts.  While not really useful, except for the initial part
any of them may be of zero length, i.e. carry no data at all.  Besides a
certain initial portion of the to be transferred data, these parts are
directly translated into what Linux calls SKB fragments.  Such converted
request parts can, when for a particular SKB they are all of length
zero, lead to a de-reference of NULL in core networking code.

IMPACT
==

An unprivileged guest can cause Denial of Service (DoS) of the host by
sending network packets to the backend, causing the backend to crash.

Data corruption or privilege escalation have not been ruled out.

VULNERABLE SYSTEMS
==

All systems using a Linux based network backend with kernel 4.14 and
newer are vulnerable.  Earlier versions may also be vulnerable.  Systems
using other network backends are not known to be vulnerable.

MITIGATION
==

Using a userspace PV network backend (e.g. the qemu based "qnic" backend)
will mitigate the problem.

Using a dedicated network driver domain per guest will mitigate the
problem.

CREDITS
===

This issue was discovered by Pratyush Yadav of Amazon.

RESOLUTION
==

Applying the attached patch resolves this issue.

xsa448-linux.patch   Linux 6.7-rc - 6.5

$ sha256sum xsa448*
f8c87cf546c2bc70970ca151c0ec8c1940f969e29c4cb3d2ec37ff9e43ddfc36  
xsa448-linux.patch
$

NOTE CONCERNING EARLY DISCLOSURE


The embargo was intended to be 2024-01-23 12:00 UTC, but a downstream
had a mixup of days and published early.

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/4UyVfoK9kFAmWutGMMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ9h0H/26sgfTHO0vnTZ8cnisn3aC5VTvrx9nY5fcCe2cJ
/KgN3q3mtb3w41/2LD/rR0Zpw4SkeTaFp69Mz2hQa37gLVDSK5lDJDR61lwhiwrQ
MSsdPHs91EDJhF6aX/S7wsQkBZYPq1S9aOuIxJbDYN3D9WsTUWvuocXNxeqTx5q9
iWVSJTH5NkRSAaIVldyNVkQ7pWaSrwqmBzolnrZIsDUjYU1Lk/j0u6GFbkOF9SIg
onFiFbJhCOaIZOIP2Tfz7nHGBnxucI4cjjwy4BWM+Va35Pg4mbHaBuVGnQsaBtVF
UdY6/jw6Qk4ktV34il3+jlgGfAFC6GILJoraASjaFCEQ7jM=
=IPLz
-END PGP SIGNATURE-


xsa448-linux.patch
Description: Binary data

Xen Security Advisory 447 v2 (CVE-2023-46837) - arm32: The cache may not be properly cleaned/invalidated (take two)

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-46837 / XSA-447
   version 2

  arm32: The cache may not be properly cleaned/invalidated (take two)

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

Arm provides multiple helpers to clean & invalidate the cache
for a given region.  This is, for instance, used when allocating
guest memory to ensure any writes (such as the ones during scrubbing)
have reached memory before handing over the page to a guest.

Unfortunately, the arithmetics in the helpers can overflow and would
then result to skip the cache cleaning/invalidation.  Therefore there
is no guarantee when all the writes will reach the memory.

This undefined behavior was meant to be addressed by XSA-437, but the
approach was not sufficient.

IMPACT
==

A malicious guest may be able to read sensitive data from memory that
previously belonged to another guest.

VULNERABLE SYSTEMS
==

Systems running all version of Xen are affected.

Only systems running Xen on Arm 32-bit are vulnerable.  Xen on Arm 64-bit
is not affected.

MITIGATION
==

There is no known mitigation.

CREDITS
===

This issue was discovered by Michal Orzel from AMD.

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.

xsa447/xsa447.patch   xen-unstable - Xen 4.17.x
xsa447/xsa447-4.16.patch  Xen 4.16.x - Xen 4.15.x

$ sha256sum xsa447* xsa447*/*
639f3a30124fd0f45b6b68768c02a5b5aa2e78c6c1f28bbf1ea5fb9be1f874af  xsa447.meta
0816717ab6e9c2250975ed1100bb2943830dc10e9a52aed7dd5cbe1884a15918  
xsa447/xsa447.patch
f325543852b28af3fb2a2ca501a70fc59d3b35432334d52f734b2071c8a9667f  
xsa447/xsa447-4.16.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/4UyVfoK9kFAmV4SxMMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZvnUIAIG4NNqHQCeBV0VOLtdZLNgaBDt9Vguc4FLUYlI5
aBc4/IWrsGYYRuBzLAPGoKYP9/F+OjiHcE0ClFnxkQJ+bFKl4SQLxmSksHkvPtpo
6yL53IbyraIbA+TulYquTr27v7ZnTI9LQA3VurD6sMgiWIo8+C/kSb6g/1TAsm4R
qzHDRLhTd4H+yU7KV327qIUk1D4S0eGP1yWpudpd0A/05RBgI9m4gp01VFeJn8w+
UbYba/4LpcAKG/iyvxqk5o3fyO60zhZEc5BBHhcz7DJ+UvLrLf7TDLrkaI6lorye
m6etZ+kWU9ESL1Qy+lHEk9HqUOg25xQb5gPDrIP3TOMSsUU=
=mrfT
-END PGP SIGNATURE-


xsa447.meta
Description: Binary data


xsa447/xsa447.patch
Description: Binary data


xsa447/xsa447-4.16.patch
Description: Binary data

Xen Security Advisory 446 v2 (CVE-2023-46836) - x86: BTC/SRSO fixes not fully effective

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-46836 / XSA-446
   version 2

x86: BTC/SRSO fixes not fully effective

UPDATES IN VERSION 2


Grammar fixes.

Public release.

ISSUE DESCRIPTION
=

The fixes for XSA-422 (Branch Type Confusion) and XSA-434 (Speculative
Return Stack Overflow) are not IRQ-safe.  It was believed that the
mitigations always operated in contexts with IRQs disabled.

However, the original XSA-254 fix for Meltdown (XPTI) deliberately left
interrupts enabled on two entry paths; one unconditionally, and one
conditionally on whether XPTI was active.

As BTC/SRSO and Meltdown affect different CPU vendors, the mitigations
are not active together by default.  Therefore, there is a race
condition whereby a malicious PV guest can bypass BTC/SRSO protections
and launch a BTC/SRSO attack against Xen.

IMPACT
==

An attacker in a PV guest might be able to infer the contents of memory
belonging to other guests.

VULNERABLE SYSTEMS
==

All versions of Xen are vulnerable.

Xen is only vulnerable in default configurations on AMD and Hygon CPUs.

Xen is not believed to be vulnerable in default configurations on CPUs
from other hardware vendors.

Only PV guests can leverage the vulnerability.

MITIGATION
==

Running only HVM or PVH VMs will avoid the vulnerability.

CREDITS
===

This issue was discovered by Andrew Cooper of XenServer.

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.

xsa446.patch   xen-unstable - Xen 4.15.x

$ sha256sum xsa446*
ed27ad5f36af31233e25c80daefb8b0078eeb18cacbc1923fdd6f10f0b394201  xsa446.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/4UyVfoK9kFAmVTfRgMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZfLoH/iZJzkNK4d6vUrx8F5Srm8mAIDMGL4fPvJz00IsO
7h7+/wz0+FdnaWgT/12kHjIJv7p38rNkyJ3UC3p55NFFGUXKQxaKjJ6YU70IdHmY
zbQDdYd2eB9dGbAq2NEkZibtg5mhhThBsQw9Sf+YZuSzOV5xRWiEhnBGz7l4+Dym
bM7vuusZo3/iUc0WgE+p+j85QmzgTFdt7VEUYY2mSTFud+hDYtvx62Ej3AkwCRdu
I0JbGYcRaDR9RPDae2d9yvz0+E473rFgOSX6DqZLjnQ+UQivZ7eo8soJD87qY4Jh
OrEDMQWysSNiT90NYWZ+HxsRRZVjPVPoxX6EWEkwC7+CffI=
=2Xtx
-END PGP SIGNATURE-


xsa446.patch
Description: Binary data

Xen Security Advisory 445 v3 (CVE-2023-46835) - x86/AMD: mismatch in IOMMU quarantine page table levels

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-46835 / XSA-445
   version 3

x86/AMD: mismatch in IOMMU quarantine page table levels

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

The current setup of the quarantine page tables assumes that the
quarantine domain (dom_io) has been initialized with an address width
of DEFAULT_DOMAIN_ADDRESS_WIDTH (48) and hence 4 page table levels.

However dom_io being a PV domain gets the AMD-Vi IOMMU page tables
levels based on the maximum (hot pluggable) RAM address, and hence on
systems with no RAM above the 512GB mark only 3 page-table levels are
configured in the IOMMU.

On systems without RAM above the 512GB boundary
amd_iommu_quarantine_init() will setup page tables for the scratch
page with 4 levels, while the IOMMU will be configured to use 3 levels
only, resulting in the last page table directory (PDE) effectively
becoming a page table entry (PTE), and hence a device in quarantine
mode gaining write access to the page destined to be a PDE.

Due to this page table level mismatch, the sink page the device gets
read/write access to is no longer cleared between device assignment,
possibly leading to data leaks.

IMPACT
==

A device in quarantine mode can access data from previous quarantine
page table usages, possibly leaking data used by previous domains that
also had the device assigned.

VULNERABLE SYSTEMS
==

All Xen versions supporting PCI passthrough are affected.

Only x86 AMD systems with IOMMU hardware are vulnerable.

Only x86 guests which have physical devices passed through to them can
leverage the vulnerability.

MITIGATION
==

Not passing through physical devices to guests will avoid the
vulnerability.

Not using quarantine scratch-page mode will avoid the vulnerability,
but could result in other issues.

CREDITS
===

This issue was discovered by Roger Pau Monné of XenServer.

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.

xsa445.patch   xen-unstable
xsa445-4.17.patch  Xen 4.17.x
xsa445-4.16.patch  Xen 4.16.x
xsa445-4.15.patch  Xen 4.15.x

$ sha256sum xsa445*
751892f1a603dbee7ecb82d046aee6d87bf10398f365d3880a7f7d32eb3d73c1  xsa445.patch
9ae729410504961578e679ba19931646802b213d026b6587fb1abb43b2629186  
xsa445-4.15.patch
55fe5925741b650fe2583a1e9855ea66c4fe0212de4fe93535fd592188fa64d4  
xsa445-4.16.patch
7c4478d348dad0d9c71685a8c402df78d74c6b4d3c3e1627115b91967e54d94a  
xsa445-4.17.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/4UyVfoK9kFAmVTfRsMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZJdUIAJOmkQjl9EbYfiuBclmQJgOik6dYwYfFRNr+Q7g0
mWWQRF9BRSZkkzKipBeFWgBkQcx/3qo5HFBfElp9Atq4JpwXlcn9iBDR9fj5Zojl
lUxKHbppKZ9lG6izHjZNVgOOmYkLBxi8STWlB4aXrxhqbgxEnv4MESC809qUuzsy
lXl8AZERW7f/L8aW5IlpQqVKskc3NXUtvrhwyegrzL5SQfeGxIl3EPChA0UGq3PC
McBQWtyMBZHmwOQco8o8QenflWpRmgO4nYHdy2CAJ5XfCqa5bgNs61AR12BAUSaS
5MLSRtCIn2VYxrfsHrE2aCYJHLvzRzWnR09N0p8DKW+4AXY=
=gjG7
-END PGP SIGNATURE-


xsa445.patch
Description: Binary data


xsa445-4.15.patch
Description: Binary data


xsa445-4.16.patch
Description: Binary data


xsa445-4.17.patch
Description: Binary data

Xen Security Advisory 444 v3 (CVE-2023-34327,CVE-2023-34328) - x86/AMD: Debug Mask handling

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory CVE-2023-34327,CVE-2023-34328 / XSA-444
   version 3

 x86/AMD: Debug Mask handling

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

AMD CPUs since ~2014 have extensions to normal x86 debugging functionality.
Xen supports guests using these extensions.

Unfortunately there are errors in Xen's handling of the guest state, leading
to denials of service.

 1) CVE-2023-34327 - An HVM vCPU can end up operating in the context of
a previous vCPUs debug mask state.

 2) CVE-2023-34328 - A PV vCPU can place a breakpoint over the live GDT.
This allows the PV vCPU to exploit XSA-156 / CVE-2015-8104 and lock
up the CPU entirely.

IMPACT
==

For CVE-2023-34327, any guest (PV or HVM) using Debug Masks normally for
it's own purposes can cause incorrect behaviour in an unrelated HVM
vCPU, most likely resulting in a guest crash.

For CVE-2023-34328, a buggy or malicious PV guest kernel can lock up the
host.

VULNERABLE SYSTEMS
==

Only AMD/Hygon hardware supporting the DBEXT feature are vulnerable.
This is believed to be the Steamroller microarchitecture and later.

For CVE-2023-34327, Xen versions 4.5 and later are vulnerable.

For CVE-2023-34328, Xen version between 4.5 and 4.13 are vulnerable.
The issue is benign in Xen 4.14 and later owing to an unrelated change.

MITIGATION
==

For CVE-2023-34327, HVM VMs which can see the DBEXT feature are not
susceptible to running in the wrong state.  By default, VMs will see the
DBEXT feature on capable hardware, and when not explicitly levelled for
migration compatibility.

For CVE-2023-34328, PV VMs which cannot see the DBEXT feature cannot
leverage the vulnerability.

CREDITS
===

This issue was discovered by Andrew Cooper of XenServer.

RESOLUTION
==

Applying the appropriate set of attached patches 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.

xsa444-?.patch   xen-unstable
xsa444-4.17-?.patch  Xen 4.17.x
xsa444-4.16-?.patch  Xen 4.16.x - Xen 4.15.x

$ sha256sum xsa444*
d1a10243d08295ffed2721aaa150efad9e9bd624428f0c24d04e69435a8ddc2e  xsa444-1.patch
9ce44c08030780c2e0432169ce679da0a5793ee254e38a0dbe506edf5f1587fd  xsa444-2.patch
ff0142be5b71679df0f425ea8f74e77589db5b5312e631541d2ab7968b9ea779  
xsa444-4.16-1.patch
4ecf44680bd95fb4adddb1c5ced21e8b2754bca2f5cf3e028cf6ea3d9a90d239  
xsa444-4.16-2.patch
9c1244f06c2cd0ad4c2023d224363d5d4ad063d80f8682ee66056520cabfb52d  
xsa444-4.17-1.patch
18dcbb62b5c5f1fba205cfbc83f3b4b1ffa39490bbfd1f1263320f8aef16e83c  
xsa444-4.17-2.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and 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/4UyVfoK9kFAmUlNO0MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZoGcH+gMuZqrzWTDFKflh1MO9EPI5iQzyJgQEHicacoBP
rO6gAUMQ2OvgqM1CO6e7qZ7qU+CPP2dfp1aR+Zxz0ynzeku2cVJY1SiAhZ+ZODso
pBZg/3DKtX0kGP27nStInbZQu2TGfTUQLJ80sYxb3A7Fl8uGWmlCFuZoYGK7R9+P
KU2sutmFJJipQVoQm38AQmTed1f+xjtX3AGwWFNGnuHkAC9pQGCQ29YL7wqhtvjw
FndF1aLLVCX5Wt6LIK6K5z8DncfrDTwXDha3XMbFmY37HGOOa96jTPJhThmnYEU1
SWc43m9HnCiP/DdBeQ9t2JmVVkx8Qc5kZQigFdpQ0aR/wj8=
=n97C
-END PGP SIGNATURE-


xsa444-1.patch
Description: Binary data


xsa444-2.patch
Description: Binary data


xsa444-4.16-1.patch
Description: Binary data


xsa444-4.16-2.patch
Description: Binary data


xsa444-4.17-1.patch
Description: Binary data


xsa444-4.17-2.patch
Description: Binary data

Xen Security Advisory 442 v2 (CVE-2023-34326) - x86/AMD: missing IOMMU TLB flushing

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-34326 / XSA-442
   version 2

  x86/AMD: missing IOMMU TLB flushing

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

The caching invalidation guidelines from the AMD-Vi specification (48882—Rev
3.07-PUB—Oct 2022) is incorrect on some hardware, as devices will malfunction
(see stale DMA mappings) if some fields of the DTE are updated but the IOMMU
TLB is not flushed.

Such stale DMA mappings can point to memory ranges not owned by the guest, thus
allowing access to unindented memory regions.

IMPACT
==

Privilege escalation, Denial of Service (DoS) affecting the entire host,
and information leaks.

VULNERABLE SYSTEMS
==

All Xen versions supporting PCI passthrough are affected.

Only x86 AMD systems with IOMMU hardware are vulnerable.

Only x86 guests which have physical devices passed through to them can
leverage the vulnerability.

MITIGATION
==

Not passing through physical devices to guests will avoid the vulnerability.

CREDITS
===

This issue was discovered by Roger Pau Monné of XenServer.

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.

xsa442.patch   xen-unstable
xsa442-4.17.patch  Xen 4.17.x - Xen 4.16.x
xsa442-4.15.patch  Xen 4.15.x

$ sha256sum xsa442*
e897c24953f33e24557666975662f74bd634e354108e7df293c1f56179ee97a9  xsa442.patch
e7413df9a217d674f8fa71cdcc18adc98201f4fca502a3bb632424e8afc32717  
xsa442-4.15.patch
0690fab47c521cae2e14e4c0cf5fcb16a7e4278ef057413ce42e0611b0739070  
xsa442-4.17.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/4UyVfoK9kFAmUlNOoMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ9rkH/RHZ6djmDOQJhRPgxJnzXnkgd36RNXkZtnMzVeYD
V4FP0QwvrkEjTfcPy/iDzkpbL9YPcr8DcXubmOuI+VxjFAlIyVkRIqOMaVKH509V
ewlSMXhCLI+yG6s61K0PqQO4KPtzpKXlevqsSn/HF8ZCIyxXvd3UfNX08342RZZZ
Aw6Wr6Q08TvDWE4CTuc1jxTcRiTHvdSd2rSAZznJbaluL/wmgoGvI2mG/NmYPe6E
aItatb9C0mPfmT/meqa3JOzJ/IOfFw+TGPkXvfTu5C2b8aCfXjcGf26r33mvkQO8
A4wKf6wisxs8ZVl0qDB0u+u2N8ihUfjopLH7QTiQzg4StyY=
=oXbA
-END PGP SIGNATURE-


xsa442.patch
Description: Binary data


xsa442-4.15.patch
Description: Binary data


xsa442-4.17.patch
Description: Binary data

Xen Security Advisory 440 v3 (CVE-2023-34323) - xenstored: A transaction conflict can crash C Xenstored

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-34323 / XSA-440
   version 3

xenstored: A transaction conflict can crash C Xenstored

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

When a transaction is committed, C Xenstored will first check
the quota is correct before attempting to commit any nodes.  It would
be possible that accounting is temporarily negative if a node has
been removed outside of the transaction.

Unfortunately, some versions of C Xenstored are assuming that the
quota cannot be negative and are using assert() to confirm it.  This
will lead to C Xenstored crash when tools are built without -DNDEBUG
(this is the default).

IMPACT
==

A malicious guest could craft a transaction that will hit the C
Xenstored bug and crash it.  This will result to the inability to
perform any further domain administration like starting new guests,
or adding/removing resources to or from any existing guest.

VULNERABLE SYSTEMS
==

All versions of Xen up to and including 4.17 are vulnerable if XSA-326
was ingested.

All Xen systems using C Xenstored are vulnerable.  C Xenstored built
using -DNDEBUG (can be specified via EXTRA_CFLAGS_XEN_TOOLS=-DNDEBUG)
are not vulnerable.  Systems using the OCaml variant of Xenstored are
not vulnerable.

MITIGATION
==

The problem can be avoided by using OCaml Xenstored variant.

CREDITS
===

This issue was discovered by Stanislav Uschakow and Julien Grall, all
from Amazon.

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.

xsa440-4.17.patch  Xen 4.17.x - Xen 4.15.x.

$ sha256sum xsa440*
187b7edef4f509f3d7ec1662901fa638a900ab4213447438171fb2935f387014  xsa440.meta
431dab53baf2b57a299d1a151b330b62d9a007715d700e8515db71ff813d0037  
xsa440-4.17.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/4UyVfoK9kFAmUlNOMMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZy64IAIZBqlKJAGVeGMzSpuJfkP2YXLe9JNeR46HRG90e
mV94MWmsf+4kMu2ZhnXQaR2+lafjNfAQVdh9nXV0tdJu//yzLRfXnLfFWrroqBTS
g69/9zvgGRYvobHe6X/WmLwXCV8N27q04zLK7R9nYwntw2mJBBCvUfRPVHk/6lpH
4Ke6o0XbjmOjForl2PA3ISRqXKD5nB0pWp1cEfPt3PzCUV02kI/N3veWDRN2wyPN
jclvwlVVASJdCrcs0+NlOalN5XhD9+K5RN+VVGu3dchXpaa3qEOiTc/V5T1U5cX8
pqNqUBlo4ECFLygE2aUTITIX+dpLaGYD8rmFq0CPnsB6E5U=
=6W84
-END PGP SIGNATURE-


xsa440.meta
Description: Binary data


xsa440-4.17.patch
Description: Binary data

Xen Security Advisory 441 v4 (CVE-2023-34324) - Possible deadlock in Linux kernel event handling

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-34324 / XSA-441
   version 4

   Possible deadlock in Linux kernel event handling

UPDATES IN VERSION 4


Public release.

Modified advisory again to state that Arm32 guests are NOT affected.

ISSUE DESCRIPTION
=

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

IMPACT
==

A (malicious) guest administrator could cause a denial of service (DoS)
in a backend domain (other than dom0) by disabling a paravirtualized
device.

A malicious backend could cause DoS in a guest running a Linux kernel by
disabling a paravirtualized device.

VULNERABLE SYSTEMS
==

All unprivileged guests running a Linux kernel of version 5.10 and later,
or with the fixes for XSA-332, are vulnerable.

All guest types are vulnerable.

Only x86- and 64-bit Arm-guests are vulnerable.

Arm-guests running in 32-bit mode are not vulnerable.

Guests not using paravirtualized drivers are not vulnerable.

MITIGATION
==

There is no known mitigation.

CREDITS
===

This issue was discovered as a bug by Marek Marczykowski-Górecki of
Invisible Things Lab; the security impact was recognised by Jürgen
Groß of SUSE.

RESOLUTION
==

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

xsa441-linux.patch Linux

$ sha256sum xsa441*
937406d86dd6dd3e389fdae726a25e5f0e960f7004c314e370cb2369d6715c24  
xsa441-linux.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) on the host and on VMs being
administered and used only by organisations which are members of the Xen
Project Security Issue Predisclosure List is permitted during the embargo,
even on public-facing systems with other 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.

Deployment of patches or mitigations is NOT permitted on VMs being
administered or used by organisations which are not members of the Xen
Project Security Issue Predisclosure List. On those VMs deployment is
permitted only AFTER the embargo ends.

(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/4UyVfoK9kFAmUlNOkMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZOmAH/3D7dRH11wIRyFZ/nj4pwkPfPXvCDtUmaRXfAaV4
Xe9ODMSevcEQpSFW4VY6eK7DP6kqYMM7myoy+np8Ttnin7+y+PYUJkxM+liqhLyT
fhGi74NNuQLMvGcSKp26aIHAJNtZqWFeRTlEFJHlY4S6ENRoupWd2T2qgnts00NX
R4NzZ8yQFcsmvy9gqgq6MYoa2VIrhQlpiDPX81pA/HViv0GiXab1QSYTyI9jQ2EX
WC19sELYSK2jMAjuejHlw28B+giy0KxcJv6zewn3Jwn8h3ft4AI1OIh4KfOtEad+
wptYB87EM76Lr3B8ipFEvN4sSU1yBnE4iVOgZpAs74mylN8=
=hOm2
-END PGP SIGNATURE-


xsa441-linux.patch
Description: Binary data

Xen Security Advisory 439 v2 (CVE-2023-20588) - x86/AMD: Divide speculative information leak

[Xen . org security team]

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

Xen Security Advisory 439 v1 (CVE-2023-20588) - x86/AMD: Divide speculative information leak

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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

 x86/AMD: Divide speculative information leak

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-7008.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= 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/4UyVfoK9kFAmURr2UMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZA1QH/RNSR1O6QJjd7z2gSGA9Yka7VWyYOMB2J01AaIl7
69zCRkpqg+baF1aQaAVR0fj39aF7M7xXrd/LSk+E4BBiCRSxxRzbWUGYn9qTLR9w
srbpGXqy0aWod9MiwfbTuEzf9uG8XpwOGoRg6p6YBRYE3WrQxIVnYY+KjeeToTEs
+UXZ0iZPrjaGaqKnF+PpkX4CMsqHhxk3iJw+ZFX2V4fVNRYgCOpjejmMjbWM4ABr
eSsCjTU92/YZvFOsTeIzu74h5yM6SH+XTPW2S8Ve5j3mk7sM8nIiYbIyTMWNCJID
HXeodt6eHjhZzV2z7f+/zEngnoITIqz+X3tRcTkHB9+H5jU=
=AtsG
-END PGP SIGNATURE-

Xen Security Advisory 438 v2 (CVE-2023-34322) - top-level shadow reference dropped too early for 64-bit PV guests

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-34322 / XSA-438
   version 2

   top-level shadow reference dropped too early for 64-bit PV guests

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

For migration as well as to work around kernels unaware of L1TF (see
XSA-273), PV guests may be run in shadow paging mode.  Since Xen itself
needs to be mapped when PV guests run, Xen and shadowed PV guests run
directly the respective shadow page tables.  For 64-bit PV guests this
means running on the shadow of the guest root page table.

In the course of dealing with shortage of memory in the shadow pool
associated with a domain, shadows of page tables may be torn down.  This
tearing down may include the shadow root page table that the CPU in
question is presently running on.  While a precaution exists to
supposedly prevent the tearing down of the underlying live page table,
the time window covered by that precaution isn't large enough.

IMPACT
==

Privilege escalation, Denial of Service (DoS) affecting the entire host,
and information leaks all cannot be ruled out.

VULNERABLE SYSTEMS
==

All Xen versions from at least 3.2 onwards are vulnerable.  Earlier
versions have not been inspected.

Only x86 systems are vulnerable.  Only 64-bit PV guests can leverage the
vulnerability, and only when running in shadow mode.  Shadow mode would
be in use when migrating guests or as a workaround for XSA-273 (L1TF).

MITIGATION
==

Running only HVM or PVH guests will avoid the vulnerability.

Running PV guests in the PV shim will also avoid the vulnerability.

CREDITS
===

This issue was discovered by Tim Deegan, and Jan Beulich of SUSE.

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.

xsa438.patch   xen-unstable
xsa438-4.17.patch  Xen 4.17.x
xsa438-4.16.patch  Xen 4.16.x
xsa438-4.15.patch  Xen 4.15.x

$ sha256sum xsa438*
f30067fa3732fb52042b14a2836b610c29af47461425f1a1ccec21cb8a5a48b1  xsa438.patch
a2e7d7c12ea19fb95e2d825fda5f7d0124cbb5c4a369cb58ab6036d266b7e297  
xsa438-4.15.patch
eb75fbeb4aa635d6104c12acd5f7311e477f7c159f2ec4eca8a345327a9aee24  
xsa438-4.16.patch
f3a305c86124e48b9afa14f3ba76b81d1f5d8d472e2412ae3d014305c749a86a  
xsa438-4.17.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/4UyVfoK9kFAmUKuSAMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZtL0IAL3mXsj7Q5Xfu/Tof0a1ie7TnpvZ2qXxzoLlyiFR
Vra9gs83Nw7n45yXFFVLSzTjmz2bCbCmUowPp6TxF9Nawt0JocbF80JpYKEojEko
6B2BAdUFhPXtx1D6NruzG2gVr5qn/eNJjIIos0o7tzxtBPLKX9qzLh3FmZK5BJm2
HyKMLIEZuVipb3Qtb+avUDHvLjee6p4eaaWOk08g3sSWhtSfwxlS4IF9j1G2Oejj
QKZ1XILCP8miXmuUZJ/L/7CzFvOm+DKNVFZYhFT0fjDWk3vNhtLcBv5s36Z65gKK
MvKe7owffmclQLWjOekYNm8dG5gQ/OkWRAPbxiwRMegT22g=
=L3du
-END PGP SIGNATURE-


xsa438.patch
Description: Binary data


xsa438-4.15.patch
Description: Binary data


xsa438-4.16.patch
Description: Binary data


xsa438-4.17.patch
Description: Binary data

Xen Security Advisory 437 v2 (CVE-2023-34321) - arm32: The cache may not be properly cleaned/invalidated

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-34321 / XSA-437
   version 2

arm32: The cache may not be properly cleaned/invalidated

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

Arm provides multiple helpers to clean & invalidate the cache
for a given region.  This is, for instance, used when allocating
guest memory to ensure any writes (such as the ones during scrubbing)
have reached memory before handing over the page to a guest.

Unfortunately, the arithmetics in the helpers can overflow and would
then result to skip the cache cleaning/invalidation.  Therefore there
is no guarantee when all the writes will reach the memory.

IMPACT
==

A malicious guest may be able to read sensitive data from memory that
previously belonged to another guest.

VULNERABLE SYSTEMS
==

Systems running all version of Xen are affected.

Only systems running Xen on Arm 32-bit are vulnerable.  Xen on Arm 64-bit
is not affected.

MITIGATION
==

There is no known mitigation.

CREDITS
===

This issue was discovered by Julien Grall of Amazon.

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.

xsa437/xsa437.patch   xen-unstable - Xen 4.17.x
xsa437/xsa437-4.16.patch  Xen 4.16.x - Xen 4.15.x

$ sha256sum xsa437* xsa437*/*
259b872275d9d77fc1744df886ffe611d933889bb5ea2833f3c7d8f554eff061  xsa437.meta
31b1a4050403fc83d4ea7619155105001cfd2f739ceb0b0cc7212ab7d0b9d559  
xsa437/xsa437.patch
ada8ba64e8562ff6016d456e08b7a171ef356cf476c643df9f66b8650009115c  
xsa437/xsa437-4.16.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/4UyVfoK9kFAmTorfoMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZIv8H/1Grce6f0aytYn0WTXyMdEXtUCkaHQd/pkNkXTe4
uOfNTBM0z2m6MUBATFNUyTiBqm+I8ywZWDp5UVW8nD2YF2hEIGrhdkDMK+cQg98q
iZ+RW4W0cIjZFTbYXRRUm6RPhp31cx4kvTHKk2+imD1bTa/4SVFyDy2ps5ybim9b
1QnPw2+Kbvd2orx6VHpCjnpTqsElRRA1phN9t87UZhgFBCeeatYizHNNqUrvBZXg
UPsB3ERyxAyMqET82jGboUfwmjpctr1I+p9UvEvY9aViSXy+SMnNi84fFSzBrOXr
EaKUg0glvV3uaNwbvJQfmgkhDUOwXN/ySO7Hcu7QpfmUn70=
=2wxR
-END PGP SIGNATURE-


xsa437.meta
Description: Binary data


xsa437/xsa437.patch
Description: Binary data


xsa437/xsa437-4.16.patch
Description: Binary data

Xen Security Advisory 434 v1 (CVE-2023-20569) - x86/AMD: Speculative Return Stack Overflow

[Xen . org security team]

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

Xen Security Advisory 435 v1 (CVE-2022-40982) - x86/Intel: Gather Data Sampling

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-40982 / XSA-435

x86/Intel: Gather Data Sampling

ISSUE DESCRIPTION
=

A researcher has discovered Gather Data Sampling, a transient execution
side-channel whereby the AVX GATHER instructions can forward the content
of stale vector registers to dependent instructions.

The physical register file is a structure competitively shared between
sibling threads.  Therefore an attacker can infer data from the sibling
thread, or from a more privileged context.

For more details, see:
  
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/gather-data-sampling.html

IMPACT
==

An attacker can infer data from different contexts on the same core.
Examples of such data includes key material, cipher and plaintext from
the AES-NI instructions, or the contents of REP-MOVS instructions,
commonly used to implement memcpy().

VULNERABLE SYSTEMS
==

Systems running all versions of Xen are affected.

See the Intel documentation for a list of affected processors.

CPUs from other hardware vendors are not believed to be affected.

MITIGATION
==

This issue can be mitigated by disabling AVX, either by booting Xen with
`cpuid=no-avx` on the command line, or by specifying `cpuid="host:avx=0"`
in the vm.cfg file of all untrusted VMs.  However, this may come with a
significant performance impact on the system and is not recommended for
anyone able to deploy the microcode and patch described below.

RESOLUTION
==

Intel are producing microcode updates to address the issue for most
affected CPUs.  Consult your dom0 OS vendor.  This microcode is
effective when late-loaded, which can be performed on a live system
without reboot.

Without microcode, disabling AVX is the only mitigation.  This is
implemented by the patches to Xen on hardware believed to be vulnerable.

In addition, to indicate safety to guest kernels, Xen needs to
synthesise new bits for guests to see, which depends on MSR_ARCH_CAPS
being visible to guests.  The work to support MSR_ARCH_CAPS is extensive
and has been going on in public in earnest since March.  The backports
to security trees are more-extensive still.

Therefore, we have decided to produce new releases on all stable trees.
Please find fixes in the respective branches under the following release
tags:

  RELEASE-4.17.2
  RELEASE-4.16.5
  RELEASE-4.15.5
  RELEASE-4.14.6

Other release activities (tarballs, announcements, etc) will happen in
due course.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmTSZQcMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZoMQH/RAjt/wZHCg/aFunhbiAbdzWmJo36Cz6KL+R2G+v
sBiPMsBvZxSikl6yeYAADgEUFKqNWQhLCAl6oaqgPbtDhFOxeZ72DRhgwZIx2KNL
85ECXk3rFhipiai6oHHbOemjPglXsyz+B5+NE64gOjpjdms9cfvfWnMnSQRF+NKa
vbpEeP+KIK1EcmKOp/xfzjjgEzg7VmJ8jnct0A77sUQYi3Ll1+ENLEcqDElP+Qob
wmM6QYkz78q/xO+R+bT+NNJ33q6JXQdixXa3ddiWrcvL/A3SveqtQh78u9daKmFM
aaivBTgJSWk0348aelEF8UjLNKx8rVRc4Dk2elioiE1PCe8=
=05gz
-END PGP SIGNATURE-

Xen Security Advisory 432 v2 (CVE-2023-34319) - Linux: buffer overrun in netback due to unusual packet

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-34319 / XSA-432
   version 2

Linux: buffer overrun in netback due to unusual packet

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

The fix for XSA-423 added logic to Linux'es netback driver to deal with
a frontend splitting a packet in a way such that not all of the headers
would come in one piece.  Unfortunately the logic introduced there
didn't account for the extreme case of the entire packet being split
into as many pieces as permitted by the protocol, yet still being
smaller than the area that's specially dealt with to keep all (possible)
headers together.  Such an unusual packet would therefore trigger a
buffer overrun in the driver.

IMPACT
==

An unprivileged guest can cause Denial of Service (DoS) of the host by
sending network packets to the backend, causing the backend to crash.

Data corruption or privilege escalation seem unlikely but have not been
ruled out.

VULNERABLE SYSTEMS
==

All systems using a Linux based network backend with kernel 3.19 and
newer are vulnerable, on the assumption that the fix for XSA-423 was
taken.  Systems using other network backends are not known to be
vulnerable.

MITIGATION
==

Using another PV network backend (e.g. the qemu based "qnic" backend)
will mitigate the problem.

Using a dedicated network driver domain per guest will mitigate the
problem.

CREDITS
===

This issue was discovered by Ross Lagerwall of Citrix.

RESOLUTION
==

Applying the attached patch resolves this issue.

xsa432-linux.patch   Linux 6.3 - 6.5-rc

$ sha256sum xsa432*
bf7acd23be1d185c40aca8b4f7700e25afd482d9ac8671ae22b021380b059091  
xsa432-linux.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/4UyVfoK9kFAmTSZKYMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZv9YH+wSW/H8BRo3hat2ssz4GOkNf/okVzOFyde0n6rsI
uPeRbRqjnd9f+rvHFIYhi9sa2MUSZ9Lg/WwmZ1YdTFXB1PBZw1iDujB1HvDu7Xlm
E0f6IkdhC17YaiBnmsUOwGhE/1wj0KOF86t92VX5skWK9NQ2OMOSYsBxHLFkNmBd
VNHApva8ICfSfUA4pXuh3Zgaw2yw8k2ZcyFN8Aixd+1Vrxq7jfZ/PUL6hfLaNjLs
a5xdj/b5+RuwRMqOI8jCFQXSgZLPDtZIIAFRi93ZMtUraARSjiN0tLpoRXsKp1u+
0T1sgTApHJGTm7jgPAz3WMCh2innRBkEVvU55hRKZ4INIbc=
=mMq6
-END PGP SIGNATURE-


xsa432-linux.patch
Description: Binary data

Xen Security Advisory 436 v1 (CVE-2023-34320) - arm: Guests can trigger a deadlock on Cortex-A77

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-34320 / XSA-436

   arm: Guests can trigger a deadlock on Cortex-A77

ISSUE DESCRIPTION
=

Cortex-A77 cores (r0p0 and r1p0) are affected by erratum 1508412
where software, under certain circumstances, could deadlock a core
due to the execution of either a load to device or non-cacheable memory,
and either a store exclusive or register read of the Physical
Address Register (PAR_EL1) in close proximity.

IMPACT
==

A (malicious) guest that doesn't include the workaround for erratum
1508412 could deadlock the core.  This will ultimately result to
a deadlock of the system.

VULNERABLE SYSTEMS
==

Systems running all version of Xen are affected.

This bug is specific to Arm Cortex-A77 cores r0p0 and r1p0.

MITIGATION
==

There are no known mitigations.

NOTE REGARDING LACK OF EMBARGO
==

This issue has been publicly documented.

RESOLUTION
==

To handle properly the erratum, it is necessary to have an updated
firmware and that both the hypervisor and guest OSes have the workaround.
This means it is not possible to security support Xen on the Cortex-A77,
even on systems which have the workaround enabled.

Applying the attached patches will document the situation and also
add the workaround in Xen if someone wish to run on Cortex-A77 with
only trusted guests.

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.

xsa436/xsa436.patch   xen-unstable - Xen 4.17.x
xsa436/xsa436-4.16.patch  Xen 4.16.x
xsa436/xsa436-4.15.patch  Xen 4.15.x

$ sha256sum xsa436* xsa436*/*
64d34753cdbbcfec2c80db2daad98529bf900935419d0214057e962098b38160  xsa436.meta
cc0f1303d4ad4c4750bd555622b87a9721e0253759b07915e6ba5216c24e8f8d  
xsa436/xsa436.patch
97d1bd7716637efce1fa5d7f608d7f26b2b396fa20b966c8c0cd22ef61dc07d4  
xsa436/xsa436-4.15.patch
e1264a44df39d56a2c6246d8f9f511d0371a5f416c364ef766ea5a59e7b46f92  
xsa436/xsa436-4.16.patch
$
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmTJGVoMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZIpMIAJJ/58V/2+aEQfc0Fd+UDegr+69PsgRVRKofbX5o
M8r0hCLoowsEvI8vxloaOCTtgEwzFq2zCYsUED1nn0iLk0MqK6t9njkuVD3cmuqt
WaVXiW7uJU8ph2pwscv2tVPBBYblT7+Y3fuHsbXEjEW40yQkStkD5NMgwH5Z0bhq
61zCZm+/xK66VBKnrWFdlTaueOLT11/lGPskISquWrYjz7Vr873k89fXdGURn6+9
N7gdl3eIDqkpGTXvUPFdPwwE+z1ESxGig24RYNQmt3UpLbIQO2wGp0HXbsJ8e1cj
r4KNhSFm/h6tsjOYxm5Jmi4an4gAOlVxCSNds2/+oZQVHpQ=
=GNOw
-END PGP SIGNATURE-


xsa436.meta
Description: Binary data


xsa436/xsa436.patch
Description: Binary data


xsa436/xsa436-4.15.patch
Description: Binary data


xsa436/xsa436-4.16.patch
Description: Binary data

Xen Security Advisory 433 v3 (CVE-2023-20593) - x86/AMD: Zenbleed

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-20593 / XSA-433
   version 3

  x86/AMD: Zenbleed

UPDATES IN VERSION 3


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.

ISSUE DESCRIPTION
=

Researchers at Google have discovered Zenbleed, a hardware bug causing
corruption of the vector registers.

When a VZEROUPPER instruction is discarded as part of a bad transient
execution path, its effect on internal tracking are not unwound
correctly.  This manifests as the wrong micro-architectural state
becoming architectural, and corrupting the vector registers.

Note: While this malfunction is related to speculative execution, this
  is not a speculative sidechannel vulnerability.

The corruption is not random.  It happens to be stale values from the
physical vector register file, a structure competitively shared between
sibling threads.  Therefore, an attacker can directly access data from
the sibling thread, or from a more privileged context.

For more details, see:
  https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html
  
https://github.com/google/security-research/security/advisories/GHSA-v6wh-rxpg-cmm8

IMPACT
==

With very low probability, corruption of the vector registers can occur.
This data corruption causes mis-calculations in subsequent logic.

An attacker can exploit this bug to read data from different contexts on
the same core.  Examples of such data includes key material, cypher and
plaintext from the AES-NI instructions, or the contents of REP-MOVS
instructions, commonly used to implement memcpy().

VULNERABLE SYSTEMS
==

Systems running all versions of Xen are affected.

This bug is specific to the AMD Zen2 microarchitecture.  AMD do not
believe that other microarchitectures are affected.

MITIGATION
==

This issue can be mitigated by disabling AVX, either by booting Xen with
`cpuid=no-avx` on the command line, or by specifying `cpuid="host:avx=0"` in
the vm.cfg file of all untrusted VMs.  However, this will come with a
significant impact on the system and is not recommended for anyone able to
deploy the microcode or patch described below.

RESOLUTION
==

AMD are producing microcode updates to address the bug.  Consult your
dom0 OS vendor.  This microcode is effective when late-loaded, which can
be performed on a live system without reboot.

In cases where microcode is not available, the appropriate attached
patch updates Xen to use a control register to avoid the 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.

xsa433.patch   xen-unstable
xsa433-4.17.patch  Xen 4.17.x
xsa433-4.16.patch  Xen 4.16.x
xsa433-4.15.patch  Xen 4.15.x
xsa433-4.14.patch  Xen 4.14.x

xsa433-bugfix.patchxen-unstable - Xen 4.14.x

$ sha256sum xsa433*
a9331733b63e3e566f1436a48e9bd9e8b86eb48da6a8ced72ff4affb7859e027  xsa433.patch
6f1db2a2078b0152631f819f8ddee21720dabe185ec49dc9806d4a9d3478adfd  
xsa433-4.14.patch
ca3a92605195307ae9b6ff87240beb52a097c125a760c919d7b9a0aff6e557c0  
xsa433-4.15.patch
e5e94b3de68842a1c8d222802fb204d64acd118e3293c8e909dfaf3ada23d912  
xsa433-4.16.patch
41d12104869b7e8307cd93af1af12b4fd75a669aeff15d31b234dc72981ae407  
xsa433-4.17.patch
b197e45aef1f47b6aebc005f876e3f593c2f32b9e5164a195f487cea6e174f75  
xsa433-bugfix.patch
$

NOTE CONCERNING TIMELINE


This issue is subject to coordinated disclosure on August 8th.  The
discoverer chose to publish details ahead of this timeline.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmTH6HQMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZlIoH/jv0CJKyFgiaOLp4DFeLfzKLHJDbLKywj0bv4Q3V
wgrWVYwzVbpPwvuArS1dOujgEosTiUggKbzDPEpHa5reVKeeLwCBFxMrU+KYRf9h
6eglOJfiW73xxyggnvQLyh3tEGY0sQF0+OFQMsN5twiXsZS0pxLPomq0slun1VkV
8ZDl4FKjmEmAurE7fOtVdvzwZ6tKVLNaGYIm4wUwNZ0Cd4qo1GHIHsvUT9ZPFc82
jwMjCwk7Ca0Iv1GMyXESwOyR/0tLm07nT9isdkXcVFNgg8JL4f2CxGK9Vt97POEw
w9KVo3SoBf+/vY4Fk4HGSXieEofzVBDjO5NkPhESEC+3oMw=
=Z3fJ
-END PGP SIGNATURE-


xsa433.patch
Description: Binary data


xsa433-4.14.patch
Description: Binary data


xsa433-4.15.patch
Description: Binary data


xsa433-4.16.patch
Description: Binary data


xsa433-4.17.patch
Description: Binary data


xsa433-bugfix.patch
Description: Binary data

Xen Security Advisory 433 v2 (CVE-2023-20593) - x86/AMD: Zenbleed

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2023-20593 / XSA-433
  version 2

  x86/AMD: Zenbleed

UPDATES IN VERSION 2


Include the CVE, which was missed accidentally in the rush of
timelines repeatedly moving underfoot.

ISSUE DESCRIPTION
=

Researchers at Google have discovered Zenbleed, a hardware bug causing
corruption of the vector registers.

When a VZEROUPPER instruction is discarded as part of a bad transient
execution path, its effect on internal tracking are not unwound
correctly.  This manifests as the wrong micro-architectural state
becoming architectural, and corrupting the vector registers.

Note: While this malfunction is related to speculative execution, this
  is not a speculative sidechannel vulnerability.

The corruption is not random.  It happens to be stale values from the
physical vector register file, a structure competitively shared between
sibling threads.  Therefore, an attacker can directly access data from
the sibling thread, or from a more privileged context.

For more details, see:
  https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html
  
https://github.com/google/security-research/security/advisories/GHSA-v6wh-rxpg-cmm8

IMPACT
==

With very low probability, corruption of the vector registers can occur.
This data corruption causes mis-calculations in subsequent logic.

An attacker can exploit this bug to read data from different contexts on
the same core.  Examples of such data includes key material, cypher and
plaintext from the AES-NI instructions, or the contents of REP-MOVS
instructions, commonly used to implement memcpy().

VULNERABLE SYSTEMS
==

Systems running all versions of Xen are affected.

This bug is specific to the AMD Zen2 microarchitecture.  AMD do not
believe that other microarchitectures are affected.

MITIGATION
==

This issue can be mitigated by disabling AVX, either by booting Xen with
`cpuid=no-avx` on the command line, or by specifying `cpuid="host:avx=0"` in
the vm.cfg file of all untrusted VMs.  However, this will come with a
significant impact on the system and is not recommended for anyone able to
deploy the microcode or patch described below.

RESOLUTION
==

AMD are producing microcode updates to address the bug.  Consult your
dom0 OS vendor.  This microcode is effective when late-loaded, which can
be performed on a live system without reboot.

In cases where microcode is not available, the appropriate attached
patch updates Xen to use a control register to avoid the 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.

xsa433.patch   xen-unstable
xsa433-4.17.patch  Xen 4.17.x
xsa433-4.16.patch  Xen 4.16.x
xsa433-4.15.patch  Xen 4.15.x
xsa433-4.14.patch  Xen 4.14.x

$ sha256sum xsa433*
a9331733b63e3e566f1436a48e9bd9e8b86eb48da6a8ced72ff4affb7859e027  xsa433.patch
6f1db2a2078b0152631f819f8ddee21720dabe185ec49dc9806d4a9d3478adfd  
xsa433-4.14.patch
ca3a92605195307ae9b6ff87240beb52a097c125a760c919d7b9a0aff6e557c0  
xsa433-4.15.patch
e5e94b3de68842a1c8d222802fb204d64acd118e3293c8e909dfaf3ada23d912  
xsa433-4.16.patch
41d12104869b7e8307cd93af1af12b4fd75a669aeff15d31b234dc72981ae407  
xsa433-4.17.patch
$

NOTE CONCERNING TIMELINE


This issue is subject to coordinated disclosure on August 8th.  The
discoverer chose to publish details ahead of this timeline.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmTA/2cMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ0EIH/02n/gvMGF5RCwfs/uvwjsQASAgELWTgAFv+tXOG
yLZWCxNkWAWDxTWAEWfdcSsLCN8GDc4c6lNuhqnV3mVsIDiGSHmXgSkI9pcCQ79T
2KTgC+ncMM4yeYTI5SUL4xvzzIQ/38t5gK5+AyPxg3jpMhCLEz2dJwbjgd4CKai+
ax+l3cX9ibLj/lQQwvgkPXweAVsfILnCAB5J1VQb1Jw0DWauYJLurMj0flz82a2O
NftdEx3b5ADDxXHdE52J5p/kpXMDohdPm0R07Y63j+eY+QJADLHfwE+n4pqyzvDf
kPEGUtxbcCj4VygmO6xrHgoHYqaGbRYeHJyHEt4jpZDLwP4=
=9wn5
-END PGP SIGNATURE-


xsa433.patch
Description: Binary data


xsa433-4.14.patch
Description: Binary data


xsa433-4.15.patch
Description: Binary data


xsa433-4.16.patch
Description: Binary data


xsa433-4.17.patch
Description: Binary data

Xen Security Advisory 433 v1 - x86/AMD: Zenbleed

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-433

  x86/AMD: Zenbleed

ISSUE DESCRIPTION
=

Researchers at Google have discovered Zenbleed, a hardware bug causing
corruption of the vector registers.

When a VZEROUPPER instruction is discarded as part of a bad transient
execution path, its effect on internal tracking are not unwound
correctly.  This manifests as the wrong micro-architectural state
becoming architectural, and corrupting the vector registers.

Note: While this malfunction is related to speculative execution, this
  is not a speculative sidechannel vulnerability.

The corruption is not random.  It happens to be stale values from the
physical vector register file, a structure competitively shared between
sibling threads.  Therefore, an attacker can directly access data from
the sibling thread, or from a more privileged context.

For more details, see:
  https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html
  
https://github.com/google/security-research/security/advisories/GHSA-v6wh-rxpg-cmm8

IMPACT
==

With very low probability, corruption of the vector registers can occur.
This data corruption causes mis-calculations in subsequent logic.

An attacker can exploit this bug to read data from different contexts on
the same core.  Examples of such data includes key material, cypher and
plaintext from the AES-NI instructions, or the contents of REP-MOVS
instructions, commonly used to implement memcpy().

VULNERABLE SYSTEMS
==

Systems running all versions of Xen are affected.

This bug is specific to the AMD Zen2 microarchitecture.  AMD do not
believe that other microarchitectures are affected.

MITIGATION
==

This issue can be mitigated by disabling AVX, either by booting Xen with
`cpuid=no-avx` on the command line, or by specifying `cpuid="host:avx=0"` in
the vm.cfg file of all untrusted VMs.  However, this will come with a
significant impact on the system and is not recommended for anyone able to
deploy the microcode or patch described below.

RESOLUTION
==

AMD are producing microcode updates to address the bug.  Consult your
dom0 OS vendor.  This microcode is effective when late-loaded, which can
be performed on a live system without reboot.

In cases where microcode is not available, the appropriate attached
patch updates Xen to use a control register to avoid the 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.

xsa433.patch   xen-unstable
xsa433-4.17.patch  Xen 4.17.x
xsa433-4.16.patch  Xen 4.16.x
xsa433-4.15.patch  Xen 4.15.x
xsa433-4.14.patch  Xen 4.14.x

$ sha256sum xsa433*
a9331733b63e3e566f1436a48e9bd9e8b86eb48da6a8ced72ff4affb7859e027  xsa433.patch
6f1db2a2078b0152631f819f8ddee21720dabe185ec49dc9806d4a9d3478adfd  
xsa433-4.14.patch
ca3a92605195307ae9b6ff87240beb52a097c125a760c919d7b9a0aff6e557c0  
xsa433-4.15.patch
e5e94b3de68842a1c8d222802fb204d64acd118e3293c8e909dfaf3ada23d912  
xsa433-4.16.patch
41d12104869b7e8307cd93af1af12b4fd75a669aeff15d31b234dc72981ae407  
xsa433-4.17.patch
$

NOTE CONCERNING TIMELINE


This issue is subject to coordinated disclosure on August 8th.  The
discoverer chose to publish details ahead of this timeline.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmS+oDEMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ4JkIAMOW9i78luUOEgggrQDp97T1CMAhew+3v+r2ZPMl
z7a6ATRU3oW7yeepYEP/1mrRFi2E09zrj0rDLvLVrYrhqeDGVIL+ZfI480508/5Y
ubRYZC13rA3jDMDu9r+oBIzObumecRAVj54j5BQmuKyXDqkDMGfbVShpMMvARvhE
wqlBXNFB1Z+ARlDrDZZo6sKhfUqHS4Fo8iilWthKxY9Eb0cxxA1PazMJz5OOaqe6
6Y3hHrSN4dq3DseAhYGgtw+BOTa/XlgAzkdlJM0DvooS22HFuHqwB7dckrtpCMlC
6I3P3p0GfsnG8U99lxYWzuEbtAKwSsFf/da2S8A4rel0aOE=
=xmQd
-END PGP SIGNATURE-


xsa433.patch
Description: Binary data


xsa433-4.14.patch
Description: Binary data


xsa433-4.15.patch
Description: Binary data


xsa433-4.16.patch
Description: Binary data


xsa433-4.17.patch
Description: Binary data

Xen Security Notice 1 v1 - winpvdrvbuild.xenproject.org potentially compromised

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Notice 1

 winpvdrvbuild.xenproject.org potentially compromised

ISSUE DESCRIPTION
=

Software running on the Xen Project hosted subdomain
winpvdrvbuild.xenproject.org is outdated and vulnerable to several
CVEs.  Some of the reported issues include remote code execution.  The
affected host was running the Jenkins build system for the Windows PV
Drivers subproject.

IMPACT
==

Since the list of CVEs reported include remote code execution we no
longer have confidence that binaries previously available at:

https://xenbits.xen.org/pvdrivers/win/

are trustworthy.  This includes binaries signed with Xen Project's EV
key that is cross-signed by Microsoft.

Note that the source code for the windows drivers, hosted on
xenbits.xen.org is in a separate system and we are confident that it
has not been tampered with.  The EV key was also not available to the
possibly compromised system.

ACTIONS TAKEN
=

The possibly compromised system has been decommissioned.

We have removed all previous binaries from:

https://xenbits.xen.org/pvdrivers/win/

A new set of drivers based on the current master branch
(9.0-unstable) and built on a trusted environment have been uploaded
on the same folder with the following hashes:

$ sha256sum xen*.tar
b089e46d52ffc64a14799c609272ccdded805c1552a88b45d95a64a27e775de7  xenbus.tar
afc6f11f9078cb457daa000b8b8d8ab69656d3950e7afbf6f40aaa5da217301a  xencons.tar
7bbcedcda5e2ffa8ab32eb3d207d1c7db5b91e22926b26d75750bfadde6611f0  xenhid.tar
a8f3344e370647696e3ed39201f5c9db693aca1c093a638fde8b7a928a4416c2  xeniface.tar
560d7049f5e321545dda25c26b5f56e0975a7f62d35629f4c9a73f0fbd148cf3  xennet.tar
9cb34cd135aab045a2401098c4044c95dbd179c454718e43045e433401b8e3dd  xenvbd.tar
47c1b9bc6e90e20d3f524036a3171cf7f8da1d94186febbae0d4a108db7bb3b5  xenvif.tar
09a4b108a9d3fca699c3c31aeb4836cfee2538e588462b0646dcccbde42a4263  xenvkbd.tar

ACTIONS IN PROGRESS
===

The security team is attempting to inspect existing binaries to
determine whether there are any obvious signs of tampering.

CREDITS
===

We would like to thank Mahmud Hasan for bringing this to our
attention.

WHAT IS AN XSN
==

A Xen Security Notice is a mechanism the Security Team was already in
the process of introducing, for providing official communication of
security-relevant information that is not of the form that fits in the
normal XSA template.  Please bear with us as we find the right balance
while trying to fast-track it into use.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmSxe3YMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZgwgH/1serMIChH2tFlbU0HSgVk07KCO17lFcCJnhDSA8
uEv3uYiW8NCZEwaD2wmgxN9tW7yTIoeSrsnTyU9D305M6gy3F9g1XcktAv9HhtEO
fS/Pdq1q/ec4vStOYUzx6yG/2GIKNYny5Um4X2Odr/dvYcdZJPkmeJtv6yIa5wSC
q3jCou/VoBCwXUGqlqzRdRsJ+srmsFfmsTn/oNuM28gkV+qRAUc+J6z+psObo2yp
KE/Jgl9B6Nq2+d7sbcgto77a/4FrgtW01qFgIbvQPcE8BBlPF4xymKeCBSGEY/yL
MrOyYpw81cOd0IvSVdQglW63+DO76EksBJJWQbtazwhbPDs=
=jmGB
-END PGP SIGNATURE-

Xen Security Advisory 431 v1 (CVE-2022-42336) - Mishandling of guest SSBD selection on AMD hardware

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-42336 / XSA-431

  Mishandling of guest SSBD selection on AMD hardware

ISSUE DESCRIPTION
=

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

IMPACT
==

An attacker with control over a guest can mislead other guests into
observing SSBD active when it is not.

VULNERABLE SYSTEMS
==

Only Xen version 4.17 is vulnerable.

Only x86 AMD systems are vulnerable.  The vulnerability can be leveraged
by and affects only HVM guests.

MITIGATION
==

Running PV guests only will prevent the vulnerability.

Setting `spec-ctrl=ssbd` on the hypervisor command line will force SSBD
to be unconditionally active.

NOTE REGARDING LACK OF EMBARGO
==

This issue was discussed in public already.

RESOLUTION
==

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

xsa431.patch   xen-unstable - Xen 4.17.x

$ sha256sum xsa431*
e71a8b7e251adf4832a4de9e452c2fd895a56314729c54698d10e344f1996a99  xsa431.patch
$
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmRjkhsMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZDb8H/0vKLOgBhwKCVc8VYm59FIALd69k4qCLcwwfDuro
jFum5ATC3Cbx+iEXD2URFY6O+eE71mMBqw3/GT/BiKvsBHQhX5lsJUpxZFscqW9J
diM69a9BYuNNy+qW3TsslRsW9WGHH5bZoAhxpNKgciE17svJ76IRUsgNf806VRX+
VBI61wK2s9oqzfTazhQVR9zxFLANTyw7M4EtUXs0y49IUFjnSeVpW7/PdoloPC1C
m0SG6HSIJ4bH+yAWMqY5GYYVgJOkaStxEM6YLGjT/V078xcDyW2cie3BOtQ8/BI0
FJ7iwEh932k7VLtd+htBF3vo7CD+teGneeaktqKK2h55ps0=
=dmhW
-END PGP SIGNATURE-


xsa431.patch
Description: Binary data

Xen Security Advisory 430 v2 (CVE-2022-42335) - x86 shadow paging arbitrary pointer dereference

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-42335 / XSA-430
   version 2

 x86 shadow paging arbitrary pointer dereference

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

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.

IMPACT
==

Guests running in shadow mode and having a PCI device passed through may be
able to cause Denial of Service and other problems, escalation of privilege
cannot be ruled out.

VULNERABLE SYSTEMS
==

Only Xen version 4.17 is vulnerable.

Only x86 systems are vulnerable.  The vulnerability can be leveraged only
by HVM guests running with shadow paging and having a PCI device passed
through.

MITIGATION
==

Not passing through PCI devices to HVM guests will avoid the vulnerability.

Running HVM guests only in HAP (Hardware Assisted Paging) mode will also
avoid the vulnerability.

CREDITS
===

This issue was discovered by Roger Pau Monné of XenServer.

RESOLUTION
==

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

xsa430.patch   xen-unstable - Xen 4.17.x

$ sha256sum xsa430*
c861cabdf546ec7583f2193f9c4f8a62579047315e5fe9eca3e9e944b67ca852  xsa430.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.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmRHr/4MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ6UsH/ib0ei76XtojIl9eaNCPoAotcGBXLDQScV133z5e
7UhW3JPUEG79+p22ACL52Km7wVtWwuL5QzbBDJaw47hTD1IwvoOTQ8Dx+KwyZGsK
H8VW8WM70XyqxRJVfA+sEIEfRnxXKfWz6qWV5n2085XzFFwbF9c+ZZ6NafGv/Jd3
75eUwyGaR0o4YEnzKpLzqYFihK56YyJmZ0+rdYYydHKUy+oVcWjrNEh41Xa6lCJX
OdZ60inTu8rizItE+xEsKLatvoKVrO9q/zhAtLm+iWldf8PTgY9tq4S89DRMD/BN
uYIAL1xBCS2HC/IyUXI63PMwHg6fYzq+0JLjtYV0IYDfYE8=
=tInZ
-END PGP SIGNATURE-


xsa430.patch
Description: Binary data

Xen Security Advisory 429 v3 (CVE-2022-42331) - x86: speculative vulnerability in 32bit SYSCALL path

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-42331 / XSA-429
   version 3

  x86: speculative vulnerability in 32bit SYSCALL path

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

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.

IMPACT
==

An attacker might be able to infer the contents of arbitrary host
memory, including memory assigned to other guests.

VULNERABLE SYSTEMS
==

Xen versions 4.5 through 4.17 are vulnerable.  Older versions are not
vulnerable.

Only x86 CPUs are potentially vulnerable.  CPUs of other architectures
are not vulnerable.

The problematic codepath is only reachable on x86 CPUs which follow
AMD's behaviour with respect to SYSCALL instructions from compatibility
mode segments.  This means that AMD and Hygon CPUs are potentially
vulnerable, whereas Intel CPUs are not.  Other vendors have not been
checked.

Only PV guests can leverage the vulnerability.

On Xen 4.16 and later, the vulnerability is only present if 32bit PV
guest support is compiled in - i.e. CONFIG_PV32=y.  On Xen 4.15 and
older, all supported build configurations are vulnerable.

The vulnerability is only present when booting on hardware that supports
SMEP or SMAP (Supervisor Mode Execution/Access Prevention).  This is
believed to be some Family 0x16 models, and all later CPUs.

MITIGATION
==

Not running untrusted PV guests will avoid the issue.

CREDITS
===

This issue was discovered by Andrew Cooper of XenServer.

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.

xsa429.patch   xen-unstable - Xen 4.16
xsa429-4.15.patch  Xen 4.15 - Xen 4.14

$ sha256sum xsa429*
2d7be90d917c475ab5217e657d2b44f5d8b107d9023dca034fcfb7feab07b2f0  xsa429.meta
36ed36dbfaad9e5df5fa87b9a3d9e9c531f476f97eeb2afe280aa238032a0540  xsa429.patch
7ac3d4182585e5d2d39231f10e7c0c9fcb972c82cf81cb884e95b628187de3a7  
xsa429-4.15.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/4UyVfoK9kFAmQZlWMMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZil4H/2b1DkLLz4RQqAgvaB8+SBeVLPqoZ7QxGLl8QXWT
AMjFdy+M5T1OtbrMvEYCZNYhZnGOJgmVagERUvg/yZbPYx28NIHjG4+u90Ot6OId
AQPqdrJ0wjEzN/ppNpnu1ALofAGbjsnAypEouGPh12gh5fcpcLQdT0rvpl2ff5f6
Qi4ShtUXhBiduBQcJ0TSneSCf5s7cq1+sMenntenK5Nrsvg7gu51YR45FyKyXdZc
raonkGDny9kmDAjdKkywS2Au2763ph9nHbW5TbD17s65AKUDTupzk+QlFPhJLIP+
/gxDoUjKFiD/eY0AABWMAFGGvHFRNvdhTfUd6ImmWhqdEeE=
=HxUJ
-END PGP SIGNATURE-


xsa429.meta
Description: Binary data


xsa429.patch
Description: Binary data


xsa429-4.15.patch
Description: Binary data

Xen Security Advisory 427 v2 (CVE-2022-42332) - x86 shadow plus log-dirty mode use-after-free

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-42332 / XSA-427
   version 2

 x86 shadow plus log-dirty mode use-after-free

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

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.

IMPACT
==

Guests running in shadow mode and being subject to migration or
snapshotting may be able to cause Denial of Service and other problems,
including escalation of privilege.

VULNERABLE SYSTEMS
==

All Xen versions from at least 3.2 onwards are vulnerable.  Earlier
versions have not been inspected.

Only x86 systems are vulnerable.  The vulnerability is limited to
migration and snapshotting of guests, and only to PV ones as well as
HVM or PVH ones run with shadow paging.

MITIGATION
==

Not migrating or snapshotting guests will avoid the vulnerability.

Running only HVM or PVH guests and only in HAP (Hardware Assisted
Paging) mode will also avoid the vulnerability.

CREDITS
===

This issue was discovered by Jan Beulich of SUSE.

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.

xsa427.patch   xen-unstable - Xen 4.17.x
xsa427-4.16.patch  Xen 4.16.x
xsa427-4.15.patch  Xen 4.15.x
xsa427-4.14.patch  Xen 4.14.x

$ sha256sum xsa427*
5ebcdc495ba6f439e47be7e17dbb8fbdecf4de66d2fac560d460f6841bd3bef3  xsa427.meta
aa39316cbb81478c62b3d5c5aea7edfb6ade3bc5e6d0aa8c4677f9ea7bcc97a2  xsa427.patch
5ba679bc2170b0d9cd4c6ce139057e3287a6ee00434fa0e9a7a02441420030ff  
xsa427-4.14.patch
410ee6be28412841ab5aba1131f7dd7b84b9983f6c93974605f196fd278562e1  
xsa427-4.15.patch
76c1850eb9a274c1feb5a8645f61ecf394a0551278f4e40e123ec07ea307f101  
xsa427-4.16.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/4UyVfoK9kFAmQZlVkMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZgRMH/RU6mB8M/feJeZDkYbrLPmT3yLiw6BpWroMTUTpv
5kIlixxlfQqyv8gqd25p5WMMKUsZlPZdLCT0iOlyMTNz6EUPRBME2Yb3ByiM7O7/
kFtlFDk5ZY5c/Vk1w0XuLm+YcABj0xnsn003YvgknmZfBJ2HWdR2iIayT/NjfQ+u
twErqUqa7il2Em5M8ZwHZeJjCUN9t+g2sv5sdI/rQeRge8ofjsquLubpgUVMGjiV
xwwUPCn3co0/2WArB4mHjWCNcoATk1NVZ3CTUyKGl5Mr+EvdmYWvzmlDa4wc8QPV
tNoASqXw0MbOOTy+RnZQHwappCDP371MirPq4IaTwiXy7eo=
=0flx
-END PGP SIGNATURE-


xsa427.meta
Description: Binary data


xsa427.patch
Description: Binary data


xsa427-4.14.patch
Description: Binary data


xsa427-4.15.patch
Description: Binary data


xsa427-4.16.patch
Description: Binary data

Xen Security Advisory 428 v3 (CVE-2022-42333,CVE-2022-42334) - x86/HVM pinned cache attributes mis-handling

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory CVE-2022-42333,CVE-2022-42334 / XSA-428
   version 3

 x86/HVM pinned cache attributes mis-handling

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

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

IMPACT
==

Entities controlling HVM guests can run the host out of resources or
stall execution of a physical CPU for effectively unbounded periods of
time, resulting in a Denial of Servis (DoS) affecting the entire host.
Crashes, information leaks, or elevation of privilege cannot be ruled
out.

VULNERABLE SYSTEMS
==

Xen versions 4.11 through 4.17 are vulnerable.  Older versions contain
the same functionality, but it is exposed there only via an interface
which is subject to XSA-77's constraints.

Only x86 systems are potentially vulnerable.  Arm systems are not
vulnerable.

Only entities controlling HVM guests can leverage the vulnerability.
These are device models running in either a stub domain or de-privileged
in Dom0.

MITIGATION
==

Running only PV or PVH guests will avoid the vulnerability.

(Switching from a device model stub domain or a de-privileged device
model to a fully privileged Dom0 device model does NOT mitigate this
vulnerability.  Rather, it simply recategorises the vulnerability to
hostile management code, regarding it "as designed"; thus it merely
reclassifies these issues as "not a bug".  The security of a Xen system
using stub domains is still better than with a qemu-dm running as a Dom0
process.  Users and vendors of stub qemu dm systems should not change
their configuration to use a Dom0 qemu process.)

CREDITS
===

Aspects of this issue were discovered by Andrew Cooper of XenServer and
Jan Beulich of SUSE.

RESOLUTION
==

Applying the appropriate set of attached patches 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.

xsa428-?.patch   xen-unstable
xsa428-4.17-?.patch  Xen 4.17.x
xsa428-4.16-?.patch  Xen 4.16.x - 4.14.x

$ sha256sum xsa428*
a7bd8d4c1e8579aeda47564efdc960cac92472387ba57d7f7a6d5d79470ebd6f  xsa428.meta
85a421d9123a56894124bed54731b8b6f2e86ad4e286871dee86efff519f4c68  xsa428-1.patch
3b691ca228592539a751ce5af69f31e09d9c477218d53af0602ac5f39f1e74d7  xsa428-2.patch
da60e01a17f9073c83098d187c07bad3a868a6b7f97dbc538cb5ea5698c51b39  
xsa428-4.16-1.patch
27718a7a86fd57624cd8500df83eb42ff3499670bc807c6555686c25e7f7b01a  
xsa428-4.16-2.patch
da60e01a17f9073c83098d187c07bad3a868a6b7f97dbc538cb5ea5698c51b39  
xsa428-4.17-1.patch
20d3b66da8fe06d7e92992218e519f4f9746791d4ba5610d84a335f38a824fcb  
xsa428-4.17-2.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/4UyVfoK9kFAmQZlkwMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZevEH/R0hCjoC/n2AJSr2dOU97c4bZmjeB5mTnWrOtOMA
AZnP68nvEzQ7OYfI4ihl+wgtKUvyVXLOWaBH9lKL8CySxrCX1r3BILMGhtDKViV4
opnKOoy0Ejg3H68x5McPhdr+PkvXWTzoNqbkUYMbNTw7ktB4Ze0mbsmKoXDUiLru
QZZ0XxtL4jc+d8GUM0k3Msy0p3lLYvIob8k6DWg7RdWxiIOxL43pKNvShgh7ZehN
P0S/PknVLpoPKzKFzMWrzakhZYYsOWoNM9U7C0zEozX4qrnsyQp3o3mvW/8MrPA+
5BKsIjSYxdleUzLSNks7Xn0nG+ki6kOrwPjFGGOGAwoR8aE=
=ILYn
-END PGP

Xen Security Advisory 426 v2 (CVE-2022-27672) - x86: Cross-Thread Return Address Predictions

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-27672 / XSA-426
   version 2

 x86: Cross-Thread Return Address Predictions

UPDATES IN VERSION 2


Xen 4.16 is vulnerable too.  The previous analysis of impacted versions
was incorrect.

The same patch is applicable to Xen 4.16, and the staging-4.16 branch
has already had the backport applied.

ISSUE DESCRIPTION
=

It has been discovered that on some AMD CPUs, the RAS (Return Address
Stack, also called RAP - Return Address Predictor - in some AMD
documentation, and RSB - Return Stack Buffer - in Intel terminology) is
dynamically partitioned between non-idle threads.  This allows an
attacker to control speculative execution on the adjacent thread.

For more details, see:
  https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1045

IMPACT
==

An attacker might be able to infer the contents of arbitrary host
memory, including memory assigned to other guests.

VULNERABLE SYSTEMS
==

Only AMD CPUs are known to be potentially vulnerable.  CPUs from other
hardware vendors are not believed to be impacted.

Only the Zen1 and Zen2 microarchitectures are believed to be potentially
vulnerable.  Other microarchitectures are not believed to be vulnerable.

Only configurations with SMT activate are potentially vulnerable.  If
SMT is disabled by the firmware, or at runtime with `smt=0` on Xen's
command line, then the platform is not vulnerable.

Xen 4.16 and later contains an optimisation, specifically:

  c/s afab477fba3b ("x86/spec-ctrl: Skip RSB overwriting when safe to do so")

which in combination with disabling 32bit PV guests (either at compile
time with CONFIG_PV32=n, or at runtime with `pv=no-32` on the command
line) renders Xen vulnerable to attack from PV guests.

Note: multiple downstreams are known to have backported this
optimisation to older versions of Xen.  Consult your software vendor
documentation.

MITIGATION
==

On otherwise-vulnerable configurations, the issue can be mitigated by
booting Xen with `spec-ctrl=rsb`, which will override the aforementioned
optimisation.

Alternatively, SMT can be disabled either in the firmware, or by booting
Xen with `smt=0`.

Alternatively, if 32bit PV guests are only runtime disabled in Xen, this
issue can also be mitigated by booting Xen with `pv=32` to enable
support 32bit PV guests.  It is not necessary for a 32bit PV guest to
actually be running in order to mitigate the issue.

RESOLUTION
==

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

xsa426.patch  xen-unstable - Xen 4.16

$ sha256sum xsa426*
425b1d8931e02852afec9fe3d9f1d009f6d8a33c6387b2e8b3896f374732d470  xsa426.patch
$
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmPuawUMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZW1UIAJ6tjOwbjPJigbSVVfyr5FRnIIYjzVBqkhL5ufvc
TQY6ZoPsEEkXzx+jJeVa3NveiegqNvIdK26exlp7n2NrrWCRWlrdGlp+/83TWfUA
gwxBzERTVBmi67+9razBYKzxKAwXO2zOHsvgSB2aCX43K+e9SvlKMny8Wp9j0Z99
SRGxzZ8D4I7kKnMMpQIGvp/rt5+k+Q2oxXmNHnIsnCGshF+Y+zK7VwlSEpFYE1ga
78XWYULa1qOEbaj+xsPtf9mMIiWfViwKkX7ZT/EPFBbFxGHSK/aeiQmWdNcFGI3D
6L7vfJIo1Xsw26ozja+C+m3cFPhNSYJDRj92oCKmLPl8iII=
=hFGs
-END PGP SIGNATURE-


xsa426.patch
Description: Binary data

Xen Security Advisory 426 v1 (CVE-2022-27672) - x86: Cross-Thread Return Address Predictions

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-27672 / XSA-426

 x86: Cross-Thread Return Address Predictions

ISSUE DESCRIPTION
=

It has been discovered that on some AMD CPUs, the RAS (Return Address
Stack, also called RAP - Return Address Predictor - in some AMD
documentation, and RSB - Return Stack Buffer - in Intel terminology) is
dynamically partitioned between non-idle threads.  This allows an
attacker to control speculative execution on the adjacent thread.

For more details, see:
  https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1045

IMPACT
==

An attacker might be able to infer the contents of arbitrary host
memory, including memory assigned to other guests.

VULNERABLE SYSTEMS
==

Only AMD CPUs are known to be potentially vulnerable.  CPUs from other
hardware vendors are not believed to be impacted.

Only the Zen1 and Zen2 microarchitectures are believed to be potentially
vulnerable.  Other microarchitectures are not believed to be vulnerable.

Only configurations with SMT activate are potentially vulnerable.  If
SMT is disabled by the firmware, or at runtime with `smt=0` on Xen's
command line, then the platform is not vulnerable.

Xen 4.17 and later contains an optimisation, specifically:

  c/s afab477fba3b ("x86/spec-ctrl: Skip RSB overwriting when safe to do so")

which in combination with disabling 32bit PV guests (either at compile
time with CONFIG_PV32=n, or at runtime with `pv=no-32` on the command
line) renders Xen vulnerable to attack from PV guests.

Note: multiple downstreams are known to have backported this
optimisation to older versions of Xen.  Consult your software vendor
documentation.

MITIGATION
==

On otherwise-vulnerable configurations, the issue can be mitigated by
booting Xen with `spec-ctrl=rsb`, which will override the aforementioned
optimisation.

Alternatively, SMT can be disabled either in the firmware, or by booting
Xen with `smt=0`.

Alternatively, if 32bit PV guests are only runtime disabled in Xen, this
issue can also be mitigated by booting Xen with `pv=32` to enable
support 32bit PV guests.  It is not necessary for a 32bit PV guest to
actually be running in order to mitigate the issue.

RESOLUTION
==

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

xsa426.patch  xen-unstable - Xen 4.17

$ sha256sum xsa426*
425b1d8931e02852afec9fe3d9f1d009f6d8a33c6387b2e8b3896f374732d470  xsa426.patch
$
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmPrzJoMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZiqsIALrisP3l7ImoKe49Bmb1blNYmUv6UjYGdVF9acc9
++QYPLq4Mu+kJuIlgKnT21hj7BFczL4KSi8sVw/nLqU3x8R/ZJ6nxXLlCod6RqGw
4MYd6QmArx8a+hm3LC0288VEFVXFh0WTDA6PK15RkspiwcjsAZ4w7DA7cRk0FLP0
9KJMhSPOAj9wCDhvOckr7DnA+D6gOKjMH83NCL0rg6Xe8+Bv0qTVYe49FqAnbWwc
9RsYOKfRuZUci+Z+mALVRB97R7xvns5D9HnDvs55ADri506JWkxmdp1GvLtjezXV
3Zds6TOrr1i0RQGV9M6aouinrI+DQNrOFR8V6p98KYxAo+Y=
=T8Uh
-END PGP SIGNATURE-


xsa426.patch
Description: Binary data

Xen Security Advisory 425 v1 (CVE-2022-42330) - Guests can cause Xenstore crash via soft reset

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-42330 / XSA-425

Guests can cause Xenstore crash via soft reset

ISSUE DESCRIPTION
=

When a guest issues a "Soft Reset" (e.g. for performing a kexec) the
libxl based Xen toolstack will normally perform a XS_RELEASE Xenstore
operation.

Due to a bug in xenstored this can result in a crash of xenstored.

Any other use of XS_RELEASE will have the same impact.

IMPACT
==

A malicious guest could try to kexec until it hits the xenstored bug,
resulting in the inability to perform any further domain administration
like starting new guests, or adding/removing resources to or from any
existing guest.

VULNERABLE SYSTEMS
==

Only Xen version 4.17 is vulnerable. Systems running an older version
of Xen are not vulnerable.

All Xen systems using C xenstored are vulnerable. Systems using the
OCaml variant of xenstored are not vulnerable.

Systems running only PV guests (x86 only) are not vulnerable, as long as
they are using a libxl based toolstack.

MITIGATION
==

The problem can be avoided by either:

- - using the OCaml xenstored variant

- - explicitly configuring guests to NOT perform the "Soft Reset" action
  by adding:
on_soft_reset="reboot"
  or similar to the guest's configuration. This will break kexec in the
  guest, though.

NOTE REGARDING LACK OF EMBARGO
==

This issue was discussed in public already.

RESOLUTION
==

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

xsa425.patch   xen-unstable, Xen 4.17.x

$ sha256sum xsa425*
49f322c955fe7857cc824bba80625e56f582fdf0a4b244f513b6750e15ba5e48  xsa425.patch
$

-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmPRQroMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZEpsIAJmIVB2lvqT2Qdp0pPSoaJIxXxuGE320kVTWmudB
F2WbRCxeubqoOC/MyHTLOujMix6wBHnbm1cMQo0r4Vah/KX34vPS3wYqDZQYZtES
aEkOQ+214QLAS2futcT0gde9idKpShI9jjWSRwcH01a7V6tlwwidc4V0luUFV0iX
EKHPJ89rbbCMP1fOq5B+C7UP8oyiHItNWPWPFBwtUeXKvFiPOoyUPCoTHG8CCYHG
WiVbeaZab7x/9+WUwXJ6hZqZiVr6NqoaItOx9Nbw4yCHwJlAj2UfA9skmqtGbPbB
vxhkbIgOeiWoPvZgTGQjzZLosWO5+y30Fv5QYIbjA2/1OSQ=
=7kiM
-END PGP SIGNATURE-


xsa425.patch
Description: Binary data

Xen Security Advisory 423 v2 (CVE-2022-3643) - Guests can trigger NIC interface reset/abort/crash via netback

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-3643 / XSA-423
  version 2

Guests can trigger NIC interface reset/abort/crash via netback

UPDATES IN VERSION 2


Patch updated.

ISSUE DESCRIPTION
=

It is possible for a guest to trigger a NIC interface reset/abort/crash in
a Linux based network backend by sending certain kinds of packets.

It appears to be an (unwritten?) assumption in the rest of the Linux network
stack that packet protocol headers are all contained within the linear
section of the SKB and some NICs behave badly if this is not the case.

This has been reported to occur with Cisco (enic) and Broadcom NetXtrem II
BCM5780 (bnx2x) though it may be an issue with other NICs/drivers as well.

In case the frontend is sending requests with split headers, netback will
forward those violating above mentioned assumption to the networking core,
resulting in said misbehavior.

IMPACT
==

An unprivileged guest can cause network Denial of Service (DoS) of the
host by sending network packets to the backend causing the related
physical NIC to reset, abort, or crash.

Data corruption or privilege escalation seem unlikely but have not been
ruled out.

VULNERABLE SYSTEMS
==

All systems using a Linux based network backend with kernel 3.19 and
newer are vulnerable. Systems using other network backends are not
known to be vulnerable.

Systems using Cisco (enic driver) and Broadcom NetXtrem II BCM5780
(bnx2x driver) NICs for guest network access are known to be vulnerable.
Systems using other NICs for guest network access cannot be ruled out
to be vulnerable.

MITIGATION
==

Using another PV network backend (e.g. the qemu based "qnic" backend)
will mitigate the problem.

Using a dedicated network driver domain per guest will mitigate the
problem.

NOTE REGARDING LACK OF EMBARGO
==

This issue was discussed in public already.

RESOLUTION
==

Applying the attached patch resolves this issue.

xsa423-linux.patch   Linux 4.14 - 6.1-rc

$ sha256sum xsa423*
e26ab5aa05cad09a26ebf12ef6e6197145937d5ae2ada6f6bb824af81ddf3916  
xsa423-linux.patch
$

-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmOQr+IMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZP1MIAL6GhGU7LQrsi1w9DC4NbnbYMJ7uwEz0k6w0++n6
IEB3+5k0Di20TdWJC7fhdi4GZMEfqfs6vJ5nN4oy3m1hsy2fU3CtEcrknba91NL/
7O9N+z6tN4Sy163Mhe/LHaaYLt/R1L98HiQQnGNaTeybJDVhrEByucKhCum7Tasr
AKcMK7M2/nevciOsbwnuAtoz9o+WQJBkVevMfjIL5NMg1wHevDM6BEzZ9bhQakY+
YIf2rSVNuEzQ84dhwa+vzvjv9Ywvwyo1iNNnavUiEtqn0ZeZkuqcL/o3g6v/WjKC
Rm4+Kc3RGSlw8i5/MB46Zq91kf9H3ccW2hyzred1byAy07g=
=x7us
-END PGP SIGNATURE-


xsa423-linux.patch
Description: Binary data

Xen Security Advisory 423 v1 (CVE-2022-3643) - Guests can trigger NIC interface reset/abort/crash via netback

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-3643 / XSA-423

Guests can trigger NIC interface reset/abort/crash via netback

ISSUE DESCRIPTION
=

It is possible for a guest to trigger a NIC interface reset/abort/crash in
a Linux based network backend by sending certain kinds of packets.

It appears to be an (unwritten?) assumption in the rest of the Linux network
stack that packet protocol headers are all contained within the linear
section of the SKB and some NICs behave badly if this is not the case.

This has been reported to occur with Cisco (enic) and Broadcom NetXtrem II
BCM5780 (bnx2x) though it may be an issue with other NICs/drivers as well.

In case the frontend is sending requests with split headers, netback will
forward those violating above mentioned assumption to the networking core,
resulting in said misbehavior.

IMPACT
==

An unprivileged guest can cause network Denial of Service (DoS) of the
host by sending network packets to the backend causing the related
physical NIC to reset, abort, or crash.

Data corruption or privilege escalation seem unlikely but have not been
ruled out.

VULNERABLE SYSTEMS
==

All systems using a Linux based network backend with kernel 3.19 and
newer are vulnerable. Systems using other network backends are not
known to be vulnerable.

Systems using Cisco (enic driver) and Broadcom NetXtrem II BCM5780
(bnx2x driver) NICs for guest network access are known to be vulnerable.
Systems using other NICs for guest network access cannot be ruled out
to be vulnerable.

MITIGATION
==

Using another PV network backend (e.g. the qemu based "qnic" backend)
will mitigate the problem.

Using a dedicated network driver domain per guest will mitigate the
problem.

NOTE REGARDING LACK OF EMBARGO
==

This issue was discussed in public already.

RESOLUTION
==

Applying the attached patch resolves this issue.

xsa423-linux.patch   Linux 4.14 - 6.1-rc

$ sha256sum xsa423*
6b11934a428ca990ee870b793c700064342b8d83bd6632a4c417de05d5c95dad  
xsa423-linux.patch
$

-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmOPXKAMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZptEIAI2kIbKXbZNr3k0riwXxH2tV4i6Ja9ad7to7CrGN
VSCOG8S5+wBhI92RnVjkifFyA4FGdHaob7AYw7X5R43rLsFKEzw06R4pP0elsGoz
w/ieETiUrdwmzIA3wx0p14kLIZdT2MWPtjuczbBYTWXVN9LGvUkIkuXLwZLOK5O5
HT2oAJhvgemcW8ThBBK0kI5Y1GxBlJ32hbQGBi6Wut6LUprZ+b3No3+/ylOfHRQG
y0vgJ5TtjdIBcJ+xY97mgmMbIRW4lI54ju4G7D6QrGl3IAPD666y2u97QwefuK4V
YigMIXIv2+PsCdo/6Vv/Fwt5g5C2PiFDr6Lx+pRNZcVIRl4=
=pbpP
-END PGP SIGNATURE-


xsa423-linux.patch
Description: Binary data

Xen Security Advisory 424 v1 (CVE-2022-42328,CVE-2022-42329) - Guests can trigger deadlock in Linux netback driver

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory CVE-2022-42328,CVE-2022-42329 / XSA-424

  Guests can trigger deadlock in Linux netback driver

ISSUE DESCRIPTION
=

The patch for XSA-392 introduced another issue which might result in
a deadlock when trying to free the SKB of a packet dropped due to
the XSA-392 handling (CVE-2022-42328).

Additionally when dropping packages for other reasons the same
deadlock could occur in case of netpoll being active for the interface
the xen-netback driver is connected to (CVE-2022-42329).

IMPACT
==

A malicious guest could cause Denial of Service (DoS) of the host via
the paravirtualized network interface.

VULNERABLE SYSTEMS
==

All systems using the Linux kernel based network backend xen-netback
are vulnerable.

MITIGATION
==

Using another PV network backend (e.g. the qemu based "qnic" backend)
will mitigate the problem.

Using a dedicated network driver domain per guest will mitigate the
problem.

NOTE REGARDING LACK OF EMBARGO
==

This issue was discussed in public already.

RESOLUTION
==

Applying the attached patch resolves this issue.

xsa424-linux.patch Linux 6.0, 6.1-rc

$ sha256sum xsa424*
89db7cad9694f498c4ac450356932fb69fb514162e07aea0343776effa821fc8  
xsa424-linux.patch
$

-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmOPXKYMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ30IH/1GZwPXXAqMjN3d1n7BotiDLfmDiNp8e92wvQvmh
cXgsBtvTZ+oDzI7J+Xr/42c4IN41s34fWl0hmNbdrw4lwrOSoj0rnCP73Bn22oUT
jbv3bmFOHytCs5crvVrA4S7dCNcdpoEmfOoSaz1cBPhMecotlgTQo7M2Cagv3O9a
a9fR+KGMk9EBDGdo2wBJyEcD9ApASPEV+LJgLoTOuYFIStCO/+TTBfJx5H7T/vgK
Dqxsq1nULCSBc5Z5wrmtF49G3asBrAbPTkRhpyp9giXU+UV0QNJclnc+IJPdLIOe
jISAvpHQ3Fkb7Q25jaBg+c0bf9KzT3ekBOaf1RofgA84Jg0=
=4J/5
-END PGP SIGNATURE-


xsa424-linux.patch
Description: Binary data

Xen Security Advisory 422 v2 (CVE-2022-23824) - x86: Multiple speculative security issues

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-23824 / XSA-422
   version 2

   x86: Multiple speculative security issues

UPDATES IN VERSION 2


Change the URL referenced for the Branch Type Confusion update.

ISSUE DESCRIPTION
=

1) Researchers have discovered that on some AMD CPUs, the implementation
   of IBPB (Indirect Branch Prediction Barrier) does not behave
   according to the specification.

   Specifically, IBPB fails to properly flush the RAS (Return Address
   Stack, also RSB - Return Stack Buffer - in Intel terminology; one of
   the hardware prediction structures), allowing attacker controlled
   values to survive across a deliberate attempt to purge said values.

   AMD have allocated CVE-2022-23824.

   For more details, see:
 https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1040


2) AMD have discovered that under some circumstances, the previous
   reported information about Branch Type Confusion (XSA-407 /
   CVE-2022-23825) was inaccurate.

   Specifically, it was previously reported that the small speculation
   window was not long enough to contain two dependent loads.  It has
   turned out not to be true, and in some circumstances, the speculation
   window is long enough to contain two dependent loads.

   AMD have not allocated a new CVE for this issue.

   For more details, see:
 
https://www.amd.com/system/files/documents/technical-guidance-for-mitigating-branch-type-confusion.pdf

IMPACT
==

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

Due to the interaction of this issue with previous speculation fixes in
their default configuration, an attacker cannot leverage this
vulnerability to infer the content of memory that belongs to Xen itself.

VULNERABLE SYSTEMS
==

Systems running all versions of Xen are affected.

Only AMD CPUs are potentially vulnerable.  CPUs from other hardware
vendors are not impacted.

Whether a CPU is potentially vulnerable depends on its
microarchitecture.  Consult your hardware vendor.

The fix for XSA-407 / CVE-2022-23825 elected, out of an abundance of
caution, to use IBPB-on-entry as a Branch Type Confusion mitigation.  It
is believed that this mitigation is still sufficient, in light of the
new discoveries.  Therefore, no changes are being provided at this time.

For CVE-2022-23824, patches are being provided on all releases as the
bug pertains to a specific speculation control not working as
documented, but there are a number circumstances where safety is
provided as a side effect of other speculative mitigations.

 * The issue is that IBPB doesn't flush the RAS (Return Address Stack).
   Also called the RSB (Return Stack Buffer) in Intel terminology.  Xen
   tends to follow Intel's terminology.

 * By default, Xen uses IBPB on a context switch from one vCPU to
   another vCPU to prevent guest to guest attacks.  This action is not
   about protecting Xen from a malicious guest; such protections are
   elsewhere.

 * By default, Xen flushes the RAS/RSB on VMExit from HVM/PVH vCPUs, in
   order to protect itself from a malicious vCPU.  Therefore, a
   malicious HVM/PVH guest cannot mount an attack using this
   vulnerability.

 * Whether Xen flushes the RAS/RSB by default on exit from PV vCPUs
   (again, to protect itself) is more complicated.  There is an
   optimisation commonly used by native OSes when the SMEP (Supervisor
   Mode Execution Prevention) feature is active, which Xen can make use
   in some cases.

   - Xen 4.15 and older flush the RAS/RSB by default.

   - Xen 4.16 introduced an optimisation to skip flushing the RAS/RSB
 when safe.  For CPUs impacted by CVE-2022-23824, this comes down to
 whether 32-bit PV guest support is enabled or not; *irrespective*
 of whether any 32-bit PV guests are actively running.

 If Xen is built with CONFIG_PV32=n, or Xen is booted with
 `pv=no-32`, or 32-bit PV guests are disabled as a side effect of
 CET being active (requires a capable toolchain, CONFIG_XEN_SHSTK=y
 or CONFIG_XEN_IBT=y, and capable hardware), then Xen will by
 default use the performance optimisation.  In this case, a
 malicious 64-bit PV guest can mount an attack using this issue.

Note: This analysis is only applicable for systems which are fully up to
date with previous speculation-related XSAs, and have not used
`spec-ctrl=` on the Xen command line to tune the speculative
mitigations.

MITIGATION
==

If there are untrusted 64-bit PV guests on the system on a Xen 4.16 or
later system, specifying `spec-ctrl=rsb` on Xen's command line and
rebooting will mitigate the vulnerability.

RESOLUTION
==

Applying the appropriate set of patches resolves this issue.

Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to 

Xen Security Advisory 422 v1 (CVE-2022-23824) - x86: Multiple speculative security issues

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-23824 / XSA-422

   x86: Multiple speculative security issues

ISSUE DESCRIPTION
=

1) Researchers have discovered that on some AMD CPUs, the implementation
   of IBPB (Indirect Branch Prediction Barrier) does not behave
   according to the specification.

   Specifically, IBPB fails to properly flush the RAS (Return Address
   Stack, also RSB - Return Stack Buffer - in Intel terminology; one of
   the hardware prediction structures), allowing attacker controlled
   values to survive across a deliberate attempt to purge said values.

   AMD have allocated CVE-2022-23824.

   For more details, see:
 https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1040


2) AMD have discovered that under some circumstances, the previous
   reported information about Branch Type Confusion (XSA-407 /
   CVE-2022-23825) was inaccurate.

   Specifically, it was previously reported that the small speculation
   window was not long enough to contain two dependent loads.  It has
   turned out not to be true, and in some circumstances, the speculation
   window is long enough to contain two dependent loads.

   AMD have not allocated a new CVE for this issue.

   For more details, see:
 https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1044

IMPACT
==

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

Due to the interaction of this issue with previous speculation fixes in
their default configuration, an attacker cannot leverage this
vulnerability to infer the content of memory that belongs to Xen itself.

VULNERABLE SYSTEMS
==

Systems running all versions of Xen are affected.

Only AMD CPUs are potentially vulnerable.  CPUs from other hardware
vendors are not impacted.

Whether a CPU is potentially vulnerable depends on its
microarchitecture.  Consult your hardware vendor.

The fix for XSA-407 / CVE-2022-23825 elected, out of an abundance of
caution, to use IBPB-on-entry as a Branch Type Confusion mitigation.  It
is believed that this mitigation is still sufficient, in light of the
new discoveries.  Therefore, no changes are being provided at this time.

For CVE-2022-23824, patches are being provided on all releases as the
bug pertains to a specific speculation control not working as
documented, but there are a number circumstances where safety is
provided as a side effect of other speculative mitigations.

 * The issue is that IBPB doesn't flush the RAS (Return Address Stack).
   Also called the RSB (Return Stack Buffer) in Intel terminology.  Xen
   tends to follow Intel's terminology.

 * By default, Xen uses IBPB on a context switch from one vCPU to
   another vCPU to prevent guest to guest attacks.  This action is not
   about protecting Xen from a malicious guest; such protections are
   elsewhere.

 * By default, Xen flushes the RAS/RSB on VMExit from HVM/PVH vCPUs, in
   order to protect itself from a malicious vCPU.  Therefore, a
   malicious HVM/PVH guest cannot mount an attack using this
   vulnerability.

 * Whether Xen flushes the RAS/RSB by default on exit from PV vCPUs
   (again, to protect itself) is more complicated.  There is an
   optimisation commonly used by native OSes when the SMEP (Supervisor
   Mode Execution Prevention) feature is active, which Xen can make use
   in some cases.

   - Xen 4.15 and older flush the RAS/RSB by default.

   - Xen 4.16 introduced an optimisation to skip flushing the RAS/RSB
 when safe.  For CPUs impacted by CVE-2022-23824, this comes down to
 whether 32-bit PV guest support is enabled or not; *irrespective*
 of whether any 32-bit PV guests are actively running.

 If Xen is built with CONFIG_PV32=n, or Xen is booted with
 `pv=no-32`, or 32-bit PV guests are disabled as a side effect of
 CET being active (requires a capable toolchain, CONFIG_XEN_SHSTK=y
 or CONFIG_XEN_IBT=y, and capable hardware), then Xen will by
 default use the performance optimisation.  In this case, a
 malicious 64-bit PV guest can mount an attack using this issue.

Note: This analysis is only applicable for systems which are fully up to
date with previous speculation-related XSAs, and have not used
`spec-ctrl=` on the Xen command line to tune the speculative
mitigations.

MITIGATION
==

If there are untrusted 64-bit PV guests on the system on a Xen 4.16 or
later system, specifying `spec-ctrl=rsb` on Xen's command line and
rebooting will mitigate the vulnerability.

RESOLUTION
==

Applying the appropriate set of patches 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.

xsa422/xsa422-?.patch   xen-unstable
xs

Xen Security Advisory 421 v2 (CVE-2022-42325,CVE-2022-42326) - Xenstore: Guests can create arbitrary number of nodes via transactions

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory CVE-2022-42325,CVE-2022-42326 / XSA-421
   version 2

 Xenstore: Guests can create arbitrary number of nodes via transactions

UPDATES IN VERSION 2


Fix typo in title.

Public release.

ISSUE DESCRIPTION
=

In case a node has been created in a transaction and it is later
deleted in the same transaction, the transaction will be terminated
with an error.

As this error is encountered only when handling the deleted node at
transaction finalization, the transaction will have been performed
partially and without updating the accounting information.  This will
enable a malicious guest to create arbitrary number of nodes.

IMPACT
==

A malicious guest can cause memory shortage in xenstored, resulting in
a Denial of Service (DoS) of xenstored.

This will inhibit creating new guests and changing the configuration
of already running guests.

VULNERABLE SYSTEMS
==

All systems running Xen version 4.9 and newer are affected.

Only systems running the C variant of Xenstore (xenstored or xenstore-
stubdom) are vulnerable.

Systems using the Ocaml variant of Xenstore (oxenstored) are not vulnerable.

MITIGATION
==

Running oxenstored instead of xenstored will avoid the vulnerability.

CREDITS
===

This issue was discovered by Julien Grall of Amazon.

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.

xsa421/xsa421-??.patch   xen-unstable, Xen 4.16.x
xsa421/xsa421-4.15-??.patch  Xen 4.15.x - 4.13.x

$ sha256sum xsa421* xsa421*/*
c2184bfb9f84220c648531e1ba13a1db0533019c999622e605a6000393e97e65  xsa421.meta
eb2c5ef828e75c79a5f2eb3274a191d3b5d13107db792b8ba2b664ef335a738e  
xsa421/xsa421-01.patch
50532ad32975fdaa2674e454da125d5d44d5b471f3cf7c91f24d4128e2e4d090  
xsa421/xsa421-02.patch
7ea5a47c293fd2379ec99ef88e29d4a19f03221aa731a600da510f61ff702be9  
xsa421/xsa421-4.15-01.patch
8198a41789ed2c63f79f64ea491d9ebbf6d31b78a47e0ff0bbf3db8257fc5f39  
xsa421/xsa421-4.15-02.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/4UyVfoK9kFAmNg+7IMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZgUUH/19VNMAsM8ROQ/MWuba28+8Y7iwwi/+fg5byAefj
vsQp+VfTODpvfQDngfqt43LhzHZ2YnUJqvsvteDiQKRrLtqakR5xrfAN5pNnzv8Q
PJQfIlsaxyVbeUWdsc2BPuQIdPi9hGGxVjpxTfLNSpbIk0E7pXzeztQKW7buxERv
vFLh358t2FBXXwpMD9qFHcTZX+tz9nVg9/0/POoiBb/7LKrmNQRJ3FmvqmgKwsyu
qzZli4eDkHouq/ay5RZKnhurbRxVe80yJ8yTE26AHgZayZUMkLRbTezKaUfkCDD1
Fb2wFmhOj0nfEl4taql2P4du5emFYezMVWy1JKP4y+4i0DQ=
=nNY0
-END PGP SIGNATURE-


xsa421.meta
Description: Binary data


xsa421/xsa421-01.patch
Description: Binary data


xsa421/xsa421-02.patch
Description: Binary data


xsa421/xsa421-4.15-01.patch
Description: Binary data


xsa421/xsa421-4.15-02.patch
Description: Binary data

Xen Security Advisory 420 v2 (CVE-2022-42324) - Oxenstored 32->31 bit integer truncation issues

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-42324 / XSA-420
   version 2

Oxenstored 32->31 bit integer truncation issues

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

Integers in Ocaml are 63 or 31 bits of signed precision.

The Ocaml Xenbus library takes a C uint32_t out of the ring and casts it
directly to an Ocaml integer.  In 64-bit Ocaml builds this is fine, but
in 32-bit builds, it truncates off the most significant bit, and then
creates unsigned/signed confusion in the remainder.

This in turn can feed a negative value into logic not expecting a
negative value, resulting in unexpected exceptions being thrown.

The unexpected exception is not handled suitably, creating a busy-loop
trying (and failing) to take the bad packet out of the xenstore ring.

IMPACT
==

A malicious or buggy guest can write a packet into the xenstore ring
which causes 32-bit builds of oxenstored to busy loop.

VULNERABLE SYSTEMS
==

All versions of Xen are affected.

Systems running a 32-bit build of oxenstored are affected.

Systems running a 64-bit build of oxenstored, or systems running (C)
xenstored are not affected.

MITIGATION
==

Running xenstored instead of oxenstored will avoid the vulnerability.

CREDITS
===

This issue was discovered by Jürgen Groß of SUSE.

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.

xsa420.patch   xen-unstable - Xen 4.13.x

$ sha256sum xsa420*
565b332d325fd0fdeb5fee890c0cd9b53c4478c46c6b7ec7b24fd3444d2dc812  xsa420.meta
bfa83ca1e78ef81f93c3d94cb1522d1cffed8b9989c5639e8ec663fad0a71027  xsa420.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/4UyVfoK9kFAmNg+68MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZWJ8H/33T8Ub00BrIWdWSvajjRA4oLamGKRg5uJoI5peJ
cpgKB7iFcoOZcM+G2YfYjm8W2ckoEHXQkJ7fJEbAW0rHc8+WyWl2ulklZSpyi9RX
B6jloIo+5pFoenShirPrJNyfbCmgJduRiUcIzPMRg6vgTmS1RO1W2x3/A6haxez5
LOJCm8dhUBbrp83KH7MgVBlUXIlVQ1irKBmCps11lFG7LaMWjLtScPI4qCpFbMf/
Cmd91Jw6EpzfOWcqohbRabqXXrPZJqSe+EwqrEJsVkkEIK2y2e/kUWcy/9shr9a2
YtudokkROE+bJGbpM9bbucCu/Rnwqj20fDIztR0soCtPbOM=
=QFv9
-END PGP SIGNATURE-


xsa420.meta
Description: Binary data


xsa420.patch
Description: Binary data

Xen Security Advisory 419 v2 (CVE-2022-42322,CVE-2022-42323) - Xenstore: Cooperating guests can create arbitrary numbers of nodes

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory CVE-2022-42322,CVE-2022-42323 / XSA-419
   version 2

   Xenstore: Cooperating guests can create arbitrary numbers of nodes

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

Since the fix of XSA-322 any Xenstore node owned by a removed domain
will be modified to be owned by Dom0.  This will allow two malicious
guests working together to create an arbitrary number of Xenstore
nodes.

This is possible by domain A letting domain B write into domain A's
local Xenstore tree.  Domain B can then create many nodes and reboot.
The nodes created by domain B will now be owned by Dom0.  By repeating
this process over and over again an arbitrary number of nodes can be
created, as Dom0's number of nodes isn't limited by Xenstore quota.

IMPACT
==

Two malicious guests working together can drive xenstored into an
out of memory situation, resulting in a Denial of Service (DoS) of
xenstored.

This inhibits creation of new guests and changing the configuration of
already running guests.

VULNERABLE SYSTEMS
==

All versions of Xen with the fix for XSA-322 are in principle vulnerable.

Both Xenstore implementations (C and Ocaml) are vulnerable.

MITIGATION
==

There is no mitigation available.

CREDITS
===

This issue was discovered by Jürgen Groß of SUSE.

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.

xsa419/xsa419-oxenstored.patch xen-unstable
xsa419/xsa419-xenstored-??.patch   xen-unstable, Xen 4.16.x
xsa419/xsa419-4.15-oxenstored.patchXen 4.15.x
xsa419/xsa419-4.15-xenstored-??.patch  Xen 4.15.x
xsa419/xsa419-4.14-oxenstored.patchXen 4.14.x
xsa419/xsa419-4.14-xenstored-??.patch  Xen 4.14.x
xsa419/xsa419-4.13-oxenstored.patchXen 4.13.x
xsa419/xsa419-4.13-xenstored-??.patch  Xen 4.13.x

$ sha256sum xsa419* xsa419*/*
eaeb2a67accac70743cd9bed055b31bee2402600b7452f79da4bb969d7b5607f  xsa419.meta
34abd947ceaf1251afc81356a3ff374bc06c046651f5f9d0894d90c93295d1ca  
xsa419/xsa419-4.13-oxenstored.patch
713eea1d9be7a5bef7a681a10648d2ea7db36c961cc8a9c55e147db14f59fbc2  
xsa419/xsa419-4.13-xenstored-01.patch
d7b0369ee1c87a08783c0484ae5f62f1c61be9c405e6568085052867bb520b2a  
xsa419/xsa419-4.13-xenstored-02.patch
f6e0cd7491d602db3a7ac9b9e94afb59c30bf8690cd116850d8eafc481f022a9  
xsa419/xsa419-4.13-xenstored-03.patch
18daa2d6b9d243bfd81e221af9ae1d74cbc621614b78dc751bb6ccdba3d66451  
xsa419/xsa419-4.14-oxenstored.patch
d631f12da2a8fcf674aeed33d0037bfff4b11587d6d52e4709739a8d1e90f33a  
xsa419/xsa419-4.14-xenstored-01.patch
dc3834b30ac15d31ad1a13a8b4925229f13ce7955f2cc2223651764c55d41e64  
xsa419/xsa419-4.14-xenstored-02.patch
f15d02bfc9ee5119347708fd2e4d26c6b4aa18827afab1a10b9139344ca88861  
xsa419/xsa419-4.14-xenstored-03.patch
95c35f32cf64229df2768109acc360a6f6ec4ddfdcbde4f0d8165f67432d3eef  
xsa419/xsa419-4.15-oxenstored.patch
773e98ee9ddb37e4a743d4435340066aabdc5fb41b6ff12e6b91c709484204ab  
xsa419/xsa419-4.15-xenstored-01.patch
4d1f9135be43e121576909787a6403aa1c1e5fa72ead8764326e21beb48d83d4  
xsa419/xsa419-4.15-xenstored-02.patch
484bdddae7a750cbddeddb93be5840e3cfdda5799f667c6b5d66c3c9b7217d55  
xsa419/xsa419-4.15-xenstored-03.patch
1c790ddc8cbabb32012c7636c46e017b0cbdd1cc23c56baabda4d5dca9531454  
xsa419/xsa419-oxenstored.patch
3c53e103f7927ae28ab5c7a3954c7d0a6fbbdce0340816936adb5938cd48c776  
xsa419/xsa419-xenstored-01.patch
978e3100b20e0126ee238d3e1c2036b25582b1ca028e120d700bac8d2a13  
xsa419/xsa419-xenstored-02.patch
57f7015289a940e7f2dc66aedb1c04d37d0aef687a7b91453582e960b7f93076  
xsa419/xsa419-xenstored-03.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of patches or mitigations is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List).  Specifically, deployment on public cloud systems
is NOT permitted.

This is because the patches will result in a guest visible change of
behavior of Xenstore.

Deployment is permitted only AFTER the embargo ends.


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

Xen Security Advisory 412 v2 (CVE-2022-42327) - x86: unintended memory sharing between guests

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-42327 / XSA-412
   version 2

   x86: unintended memory sharing between guests

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

On Intel systems that support the "virtualize APIC accesses" feature, a
guest can read and write the global shared xAPIC page by moving the
local APIC out of xAPIC mode.

Access to this shared page bypasses the expected isolation that should
exist between two guests.

IMPACT
==

Guests are able to access an unintended shared memory page.  Note the
contents of the page are not interpreted by Xen or hardware.

VULNERABLE SYSTEMS
==

Only Xen version 4.16 is vulnerable.  Other Xen versions are not vulnerable.

x86 HVM or PVH guests running on Intel systems with the "virtualize APIC
accesses" feature are affected.  This is believed to be all 64-bit
capable Intel CPUs.

x86 HVM or PVH guests running on AMD hardware, Arm or x86 PV guests are
not affected.

MITIGATION
==

Only running PV guests will mitigate the vulnerability on affected
hardware.

CREDITS
===

This issue was discovered by Andrew Cooper of Citrix.

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.

xsa412.patch   xen-unstable
xsa412-4.16.patch  Xen 4.16.x

$ sha256sum xsa412*
64107d4a185dc3cdbc59400d724fe2ada490d39c14ab354aa73bb67a94ca0f65  xsa412.meta
425c1cc3e25f67746a3074aa6304dd0d915f503ea57440b9ecdb583e1547a8fe  xsa412.patch
b030bebbc4798e1d1ad75d763294ce25609f9f895402272a1f354d781f6f5f00  
xsa412-4.16.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.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmNg+5sMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZF10H/2C2pgVmiJWW6iZNMTDHuV4EyZJTFPCBnKR3qirj
3fffRN15gjzPLZZH+Ivwj3ZeWyQBLkGqC1EFemLtWpQePYlcRoH4mCyE4jc8dx89
Ejh2Zfaib0GIJoHqqDYnRQV8/BusGjIRNgWG2zAEuj+ElHRYtXcd4G5/swtcmKyN
/lSn5VMVrTGdfyGmQtcou24fK5sfzDrfCJm8pThUT6x+ERAUtCYWx2SG3fA1x55R
hWc846qJPXay/BOI0F/d23QkOP+jZsCjhbe+xnTEfgGEq32ZvwhFgkz1/DuXHl0j
hBrWjRzhLd8+mCmnXeXURDHbPmyg47TDsSg4n1VeRBJUKrc=
=as4H
-END PGP SIGNATURE-


xsa412.meta
Description: Binary data


xsa412.patch
Description: Binary data


xsa412-4.16.patch
Description: Binary data

Xen Security Advisory 415 v2 (CVE-2022-42310) - Xenstore: Guests can create orphaned Xenstore nodes

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-42310 / XSA-415
   version 2

  Xenstore: Guests can create orphaned Xenstore nodes

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

By creating multiple nodes inside a transaction resulting in an error,
a malicious guest can create orphaned nodes in the Xenstore data base,
as the cleanup after the error will not remove all nodes already
created. When the transaction is committed after this situation, nodes
without a valid parent can be made permanent in the data base.

IMPACT
==

A malicious guest can cause inconsistencies in the xenstored data base,
resulting in unusual error responses or memory leaks in xenstored. This
can finally cause Denial of Service situations or long running error
recoveries of xenstored.

VULNERABLE SYSTEMS
==

Systems with Xen version 4.9 and newer running the C variant of Xenstore
(xenstored or xenstore-stubdom) are vulnerable.

Systems using the Ocaml variant of Xenstore (oxenstored) are not vulnerable.

MITIGATION
==

Using oxenstored will avoid the vulnerability.

CREDITS
===

This issue was discovered by Julien Grall of Amazon.

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.

xsa415.patch   xen-unstable, Xen 4.16.x
xsa415-4.15.patch  Xen 4.15.x
xsa415-4.14.patch  Xen 4.14.x - 4.13.x

$ sha256sum xsa415*
ff973fd3d0af2b45ba46ba74410204a60fcba30b0d0830c591dc827eac9ae484  xsa415.meta
bc5b33bbef18c0fb15d6da6760ece9ef7f6f2cfab78664aee533ff717b379e3b  xsa415.patch
243e7e35ba94973252a6381977af2cf70774abfd0bfd5d0015179b94c832453e  
xsa415-4.14.patch
7b18b510b811551025cd2a86d654ee776b5003172ab468e7e86a0c6d892f4629  
xsa415-4.15.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/4UyVfoK9kFAmNg+6IMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZm88H/inrzV4zw8Po/g59rq1hUrCE/L4KwAemf5ZmWMK8
Unka74TyN2j47wous4EbBstzQQtOvf7GP2OT68qpIlqaZSAGcu+7x6TPx3M8q8kM
ZFzqcDYvNye8KrUCNp9pVJIV2Y8b3JLAZXCvxxGK++yECGMjTh5ZkxzdiNK/t9NO
+TmhH7CHFzkiO25Ch/8+vlwMs6eH/rKFLUVbEU/ZiD9L/P84xQr1EORhAhDJorx1
SLyprG0BlaCUIA/YbQVEftqHiG0J6ikuBYJGBHyQGVEV/MqSXGCUB/Eee6nzH4fH
1USXmeQ27OMsKwOJXyxFvrCgmKdeTNDcx0KSzSPFrED9rSc=
=hu/k
-END PGP SIGNATURE-


xsa415.meta
Description: Binary data


xsa415.patch
Description: Binary data


xsa415-4.14.patch
Description: Binary data


xsa415-4.15.patch
Description: Binary data

Xen Security Advisory 414 v2 (CVE-2022-42309) - Xenstore: Guests can crash xenstored

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-42309 / XSA-414
   version 2

 Xenstore: Guests can crash xenstored

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

Due to a bug in the fix of XSA-115 a malicious guest can cause xenstored
to use a wrong pointer during node creation in an error path, resulting
in a crash of xenstored or a memory corruption in xenstored causing
further damage.

Entering the error path can be controlled by the guest e.g. by exceeding
the quota value of maximum nodes per domain.

IMPACT
==

A malicious guest can cause xenstored to crash, resulting in the inability
to create new guests or to change the configuration of running guests.

Memory corruption in xenstored or privilege escalation of a guest can't
be ruled out.

VULNERABLE SYSTEMS
==

All Xen versions with the fix for XSA-115 running the C variant of Xenstore
(xenstored or xenstore-stubdom) are vulnerable.

Systems using the Ocaml variant of Xenstore (oxenstored) are not vulnerable.

MITIGATION
==

Using oxenstored instead of xenstored will avoid the vulnerability.

CREDITS
===

This issue was discovered by Julien Grall of Amazon.

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.

xsa414.patch   xen-unstable, Xen 4.16.x - 4.15.x
xsa414-4.14.patch  Xen 4.14.x - 4.13.x

$ sha256sum xsa414*
aad9be1af22eec504bf45ff651509be9106e7d4ceb7552befcf3152a17e5efbe  xsa414.meta
f0683bce3b27dd516367091e845559359c12a193b4e051867b580ea46d58359f  xsa414.patch
6eb053052786c738abaf747ea69384fd47525186fa6b6ea247383c7cbfbf3e07  
xsa414-4.14.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/4UyVfoK9kFAmNg+58MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZYVAH/1m7ox0cI4jg17wM8ri+cWi0O4bp68MFQKG887DJ
2WZsObdY3SYkUO1YBMg9qu9l5G11+z3UW8KBznafVPweyt35CZJdq6E82SfNc+uf
6/9hmDvXl3fwNJDP9AQBEKMXHPMjRYmIPaniuQdRgnqKSZNUXefbyHZFuHqKabSq
cIEJebNHyNWYmC5fulu53YHuX2WHCkUhlcYYLfqbqd+THGt6Aqj+1NxS3QZ/7zBC
Jiw1eLjzyOGeARkmobl9FJuQpyB9ZmiyenrJCzFMR3uh0njMnMys95VgWxBH+uBe
ooe2vvcoE9EpY8MPmV3UhA+q3JsIis+dkZ2vJQAjaQAomXQ=
=NNSk
-END PGP SIGNATURE-


xsa414.meta
Description: Binary data


xsa414.patch
Description: Binary data


xsa414-4.14.patch
Description: Binary data

Xen Security Advisory 417 v2 (CVE-2022-42320) - Xenstore: Guests can get access to Xenstore nodes of deleted domains

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-42320 / XSA-417
   version 2

 Xenstore: Guests can get access to Xenstore nodes of deleted domains

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

Access rights of Xenstore nodes are per domid.  When a domain is gone,
there might be Xenstore nodes left with access rights containing the
domid of the removed domain.  This is normally no problem, as those
access right entries will be corrected when such a node is written
later.

There is a small time window when a new domain is created, where the
access rights of a past domain with the same domid as the new one will
be regarded to be still valid, leading to the new domain being able to
get access to a node which was meant to be accessible by the removed
domain.  For this to happen another domain needs to write the node
before the newly created domain is being introduced to Xenstore by
dom0.

IMPACT
==

In some circumstances, it might be possible for a new guest domain to
access resources belonging to a previous domain.  The impact would
depend on the software in use and the configuration, but might include
any of denial of service, information leak, or privilege escalation.

VULNERABLE SYSTEMS
==

All versions of Xen are in principle vulnerable.

Only systems running the C variant of Xenstore (xenstored or xenstore-
stubdom) are vulnerable.

Systems using the Ocaml variant of Xenstore (oxenstored) are not vulnerable.

Vulnerable systems are only those running software where one domain is
granted access to another's xenstore nodes, without complete cleanup
of those nodes on domain destruction.  No such software is enabled in
default configurations of upstream Xen.

Therefore upstream Xen, without additional management software (in
host or guest(s)), is not vulnerable in the default (host and guest)
configuration.

MITIGATION
==

Running oxenstored instead of xenstored will avoid the vulnerability.

CREDITS
===

This issue was discovered by Jürgen Groß of SUSE.

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.

xsa417.patch   xen-unstable, Xen 4.16.x - 4.13.x

$ sha256sum xsa417*
62b37c77cc97374685d1df31da57809ddd6c9ad2272fb3380555e81dc85f0cd8  xsa417.meta
b0c3bdc1723ead350c86b5a42f5e28445fa331ba5f463d82385fdaeb80119b30  xsa417.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-

iQE/BAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmNg+6gMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZCj8H93lp5U3OwMNzzrurILUGMY/N6rcGnuoWqa91FslA
C7PSK+A51TvrODUi7bo3YQ1mImW75NmyasMey7/I78DUdHuRwj4L9XOI+W9J5ePk
oSVBja6jUC6LawLxj21DBP1rhufqVnJ0lOsO6rK+v/awJOkANH1nstUksqvxPmKa
ESMDudyo4+2wWH/DKizq6FYexyEQ/rlCktWZTQi1T1PXFX5xMOk+dzd+SSxifX/7
BSLc/HdRzNt1UemKtKvw7KJqCys0Sw8EWAwu6vpQCqczNbkM8CmhzapSWc+IyCZ3
RMOxk9OuW8+6/9D0s4oqWJ7lV4UfW1kZ8euPeybEhLXo5w==
=Kkzx
-END PGP SIGNATURE-


xsa417.meta
Description: Binary data


xsa417.patch
Description: Binary data

Xen Security Advisory 413 v2 (CVE-2022-33749) - XAPI open file limit DoS

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-33749 / XSA-413
   version 2

   XAPI open file limit DoS

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

It is possible for an unauthenticated client on the network to cause
XAPI to hit its file-descriptor limit. This causes XAPI to be unable
to accept new requests for other (trusted) clients, and blocks XAPI
from carrying out any tasks that require the opening of file
descriptors.

IMPACT
==

An attacker is capable of blocking connections to the XAPI HTTP
interface, and also interrupt ongoing operations, causing a XAPI
toolstack Denial of Service.  Such DoS would also affect any guests
that require toolstack actions.

VULNERABLE SYSTEMS
==

All versions of XAPI are vulnerable.

Systems which are not using the XAPI toolstack are not vulnerable.

MITIGATION
==

Not exposing to untrusted clients the network interface XAPI is
listening on will prevent the issue.

RESOLUTION
==

Applying the attached patches resolves this issue.

xsa413/xsa413-*.patch Xapi master

$ sha256sum xsa413*/*
63f72af7a92944700318add5cc200160ff7f834b6d304dd22441fa2de74c7b83  
xsa413/xsa413-1.patch
6fbcbfb1915ebc4a726374d94e050406d8f1d52c3cb9afc06bcf7cec9e5a19c8  
xsa413/xsa413-2.patch
c41de04ff2b63756e693c6c75ec4d7206a88db06c1da0b263c9d0644da90ef8b  
xsa413/xsa413-3.patch
6ee2dc09f6c5f64ce9627e9b4e314237817f7c0c2eebe30a2c83709d1faf0050  
xsa413/xsa413-4.patch
360a5099ece45118488706acd76b6da3ca8e6f107cee24586dbf6ec7f5858aeb  
xsa413/xsa413-5.patch
cc79e086affcfd784ab8cd38e1d0acd6adb241c24141f3409161e417cc314b28  
xsa413/xsa413-6.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.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmNFTAEMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZmIMH/RBAGOrAi8NI7BBeGHwMW7WqyMfT6mTVUFkb2z9z
ZFtvPFvim5AobCUpAKFtUAWpSQoUEEPyTO83C2VDe9jQC37mRo/qAduX7wj8oaJv
Dq+QFECP95bsfmu0SwKYL7ZW+3lLxDVwtp88z4P/H/U0VYqG+bNrR569znBbn0wL
p7EKQG5A4PS0nLg8ehnxjwuKCn0dCgUIZibh3AIMOUDTFY/apVeDFbX7bKIoQgLV
/0B18MevryxqSRe3QpL2WW/kRGLLKF7i5SA7nAbOPMzPWHOLNDZb+b+Hq7/eYwzI
a2+6yUcBkWAqyi9M3fXkhslySA/WqLdPXBIkd47zZS9rIuU=
=Ih6z
-END PGP SIGNATURE-


xsa413/xsa413-1.patch
Description: Binary data


xsa413/xsa413-2.patch
Description: Binary data


xsa413/xsa413-3.patch
Description: Binary data


xsa413/xsa413-4.patch
Description: Binary data


xsa413/xsa413-5.patch
Description: Binary data


xsa413/xsa413-6.patch
Description: Binary data

Xen Security Advisory 411 v3 (CVE-2022-33748) - lock order inversion in transitive grant copy handling

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-33748 / XSA-411
   version 3

lock order inversion in transitive grant copy handling

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

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.

IMPACT
==

Malicious or buggy guest kernels may be able to mount a Denial of
Service (DoS) attack affecting the entire system.

VULNERABLE SYSTEMS
==

Xen versions 4.0 and newer are vulnerable.  Xen versions 3.4 and older
are not vulnerable.

Only guests with access to transitive grants can exploit the
vulnerability.  In particular, this means that:

 * ARM systems which have taken the XSA-268 fix are not vulnerable, as
   Grant Table v2 was disabled for other security reasons.

 * All systems with the XSA-226 fixes, and booted with
   `gnttab=max-ver:1` or `gnttab=no-transitive` are not vulnerable.

 * From Xen 4.16, the maximum grant table version can be controlled on a
   per-domain basis.  For the xl toolstack, the vulnerability does not
   manifest if either:

   1) Every guest has `max_grant_version=1` in their configuration file,
  or

   2) The global xl.conf has `max_grant_version=1`, and no guests have
  the default overridden by selecting `max_grant_version=2`.

Only multiple cooperating guests can exploit the vulnerability.

MITIGATION
==

Disallowing the use of transitive grants either via the
`gnttab=no-transitive` Xen command line option, or by disabling grant
interface version 2 altogether via the `gnttab=max-ver:1` Xen command
line option or the xl controls as mentioned above will avoid the
vulnerability.

CREDITS
===

This issue was discovered by Jan Beulich of SUSE.

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.

xsa411.patch   xen-unstable - Xen 4.15.x
xsa411-4.14.patch  Xen 4.14.x - 4.13.x

$ sha256sum xsa411*
0802e2e4e9d03c82429a710bbb783cee2fded52d29b1d969b97c680d30c3ac57  xsa411.patch
8473f2ee34562298c5174f0a5b3c64c561a945333aab675845093ad23250d1cf  
xsa411-4.14.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches 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.

HOWEVER, deployment of the mitigations is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List).  Specifically, deployment on public cloud systems
is NOT permitted.

This is because it is a guest visible change which will draw attention
to the issue.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmNFTAAMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZPsQH/1JCqscbx49QygGVEnq43C97HQpcoZcUNJGwGjBJ
Li0SXejxd3iWsYsFlMAgmacHIjevEGv318JJLSM21hBULGe85cc6QatpWS0VWrBc
tQVbDIgqNRv42gJCtf1dLF0TnlTZ6p3wiqfsxEYBn1zlEhe2ZEMpY8an4707O32d
nQ90JFh44QJXx6HMZD3pEw2g1+4pMDu9yDUp/Yc3YmxYnXmPW6KE7iMmGkLLGigI
GfiTI4FA/BDVIZkjPErwG7pyXmp2sdtVkv5o/cg7YTOrLzeBmegdyUvzuXkizJ2F
PQnc1rgS/vXPkC62cy6fmLkeAf0dQhq6KBuxW3N8s2fXRXk=
=/bRo
-END PGP SIGNATURE-


xsa411.patch
Description: Binary data


xsa411-4.14.patch
Description: Binary data

Xen Security Advisory 408 v3 (CVE-2022-33745) - insufficient TLB flush for x86 PV guests in shadow mode

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-33745 / XSA-408
   version 3

insufficient TLB flush for x86 PV guests in shadow mode

UPDATES IN VERSION 3


Update hash for metadata file.

ISSUE DESCRIPTION
=

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.

IMPACT
==

The known (observed) impact would be a Denial of Service (DoS) affecting
the entire host, due to running out of memory.  Privilege escalation and
information leaks cannot be ruled out.

VULNERABLE SYSTEMS
==

All versions of Xen with the XSA-401 fixes applied are vulnerable.

Only x86 PV guests can trigger this vulnerability, and only when running
in shadow mode.  Shadow mode would be in use when migrating guests or as
a workaround for XSA-273 (L1TF).

MITIGATION
==

Not running x86 PV guests will avoid the vulnerability.

CREDITS
===

This issue was discovered by Charles Arnold of SUSE.

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.

xsa408.patch   xen-unstable - Xen 4.14.x
xsa408-4.13.patch  Xen 4.13.x

$ sha256sum xsa408*
9411b563c71445d2c95e36aba9d71fa3b9341f0230e4b3e2549a63292df11669  xsa408.meta
f49cb67842c7576f1d59b965331956a9fa1f529a8e2da3531d7ebc4eb3f079b3  xsa408.patch
26871efbd3f834dd4af4fbab6f2cb09a83c509e49894f025ee656071419ed995  
xsa408-4.13.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/4UyVfoK9kFAmLgPzsMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZT5cIAKtisZZvdcSolZ+RHFzAdVEP2lbEW2TyoG6oy0st
kMsV/ZSabthow9PiUp48DoZOXSIh/7hn2qyXqx5X0VYjiWOISVRCldm5g4p0+tA/
GN6FztbRR1GargLkvtuWj38K9E7HIqfBRFLbtJD6X97NFSAPeNNZg8nqQPqwkhK+
yeGBjPPO5pTjNwsRt91A1qEttTPjbBpipEcit/qjqqCBxX6NT/pYSE5Ltn2OHm38
eYM25X901rJl0rPsyOeUN312FAL0bEunKVKJbiNcHVBZoR37YoJ5HE5trDxoxPrz
XYJdR7gzcB028lbGU4jt9FVHdYCh0htWpdpdWci4A3DCH7U=
=C02g
-END PGP SIGNATURE-


xsa408.meta
Description: Binary data


xsa408.patch
Description: Binary data


xsa408-4.13.patch
Description: Binary data

Xen Security Advisory 408 v2 (CVE-2022-33745) - insufficient TLB flush for x86 PV guests in shadow mode

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-33745 / XSA-408
   version 2

insufficient TLB flush for x86 PV guests in shadow mode

UPDATES IN VERSION 2


Added metadata

Public release.

ISSUE DESCRIPTION
=

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.

IMPACT
==

The known (observed) impact would be a Denial of Service (DoS) affecting
the entire host, due to running out of memory.  Privilege escalation and
information leaks cannot be ruled out.

VULNERABLE SYSTEMS
==

All versions of Xen with the XSA-401 fixes applied are vulnerable.

Only x86 PV guests can trigger this vulnerability, and only when running
in shadow mode.  Shadow mode would be in use when migrating guests or as
a workaround for XSA-273 (L1TF).

MITIGATION
==

Not running x86 PV guests will avoid the vulnerability.

CREDITS
===

This issue was discovered by Charles Arnold of SUSE.

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.

xsa408.patch   xen-unstable - Xen 4.14.x
xsa408-4.13.patch  Xen 4.13.x

$ sha256sum xsa408*
7349445d53b68bc8e2be2aea9fa20409a9b87e0d6b78fc2515093a65668444a0  xsa408.meta
f49cb67842c7576f1d59b965331956a9fa1f529a8e2da3531d7ebc4eb3f079b3  xsa408.patch
26871efbd3f834dd4af4fbab6f2cb09a83c509e49894f025ee656071419ed995  
xsa408-4.13.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/4UyVfoK9kFAmLfyP4MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZSkAIAM3XDzBdUXux7ONc9nztSMGPBdWosC5f0SycveSq
adplJeShw50aFYLxpZzqfCBAX/Jh0ooF+7gHnjVMuKKkg8vu5SfBpSGRdmva6jpc
qNXoNyIc21PdNH4PVCKDQnO8Dq8wPSCnPpMZbFwk2uz7QGN5BKU/GM6XQrmXA3wz
3XYIcVVR377MdDuR8UQKyCSAG0JPr6SiozygRFHykGjg9NABWZwGyod64C9xBAyu
K8CGTx12bAJEVcqJbGAVSEU6J5iKdWjSLHwy43ZOcAFvfiCAlolBOPlfjJTllYdQ
Yhv0wQtOwsIDjQU6vbUtMsckuNEmfMPTEkRHPOpp46dPuVk=
=33sr
-END PGP SIGNATURE-


xsa408.meta
Description: Binary data


xsa408.patch
Description: Binary data


xsa408-4.13.patch
Description: Binary data

Xen Security Advisory 405 v3 (CVE-2022-33743) - network backend may cause Linux netfront to use freed SKBs

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-33743 / XSA-405
   version 3

   network backend may cause Linux netfront to use freed SKBs

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

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.

IMPACT
==

A misbehaving or malicious backend may cause a Denial of Service (DoS)
in the guest.  Information leaks or privilege escalation cannot be
ruled out.

VULNERABLE SYSTEMS
==

Linux versions 5.9 - 5.18 are vulnerable.  Linux versions 5.8 and
earlier are not vulnerable.

This vulnerability only increases the capability of an attacker in systems
with less than fully privileged network backends (e.g. network driver
domains).  For systems where netback runs in dom0 (the default
configuration), this vulnerability does not increase the capabilities of
an attacker.

MITIGATION
==

There is no mitigation available other than not using PV devices in case
a backend is suspected to be potentially malicious.

CREDITS
===

This issue was discovered by Jan Beulich of SUSE.

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.

xsa405-linux.patch Linux 5.9 - 5.19-rc

$ sha256sum xsa405*
69716b78fbd996bce0414079bbb5f002029c5a82924aaae0db78a13c4b385f0a  
xsa405-linux.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of patches or mitigations is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List).  Specifically, deployment on public cloud systems
is NOT permitted.

This is because the patches need to be applied in the affected guests.
Switching from PV to non-PV devices is observable by the guests and has
usually a bad performance impact.

Deployment is permitted only AFTER the embargo ends.

(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/4UyVfoK9kFAmLEFgAMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZgG4H/3KYUQdJlSEq2AEmIZhh1HDdhj/9n9Wxm0eHEqEQ
pXvflqbqb2glZpQyWcFPcY4oRRYvy58p9FIEi3PJD+52K/7h58XcTEZKDFP87z53
iqATbN4s/wHQ45xWAuIEHsmfLRtj3gIr4qviux3dtygKMjo6cZDX7Ethv6j0xdgc
lEUfvisH+3ZXG+JOQbZyxmi6g1SGDf1TJQczXR1rJjIp/npTupfFO+4r+vpiypbI
6ytFrRwmqfzuO8Mz5Wqrda8Fkk3JYoYtJdBfd/hYNu5vBN0d4o82sbZpuzVgdRI4
H+R90MB1XpZJ/mSYEDBbEctbmTFfJrRvr9yGjtCi8ivvQ5I=
=fMa/
-END PGP SIGNATURE-


xsa405-linux.patch
Description: Binary data

Xen Security Advisory 403 v3 (CVE-2022-26365,CVE-2022-33740,CVE-2022-33741,CVE-2022-33742) - Linux disk/nic frontends data leaks

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory 
CVE-2022-26365,CVE-2022-33740,CVE-2022-33741,CVE-2022-33742 / XSA-403
  version 3

  Linux disk/nic frontends data leaks

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

Linux Block and Network PV device frontends don't zero memory regions before
sharing them with the backend (CVE-2022-26365, CVE-2022-33740).  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 (CVE-2022-33741, CVE-2022-33742).

IMPACT
==

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.

VULNERABLE SYSTEMS
==

All Linux guests using PV devices are vulnerable in case potentially
malicious PV device backends are being used.

MITIGATION
==

There is no mitigation available other than not using PV devices in case
a backend is suspected to be potentially malicious.

CREDITS
===

The issue related to not zeroing memory areas used for shared communications
was discovered by Roger Pau Monné of Citrix.

The issue related to leaking contiguous data in granted pages was disclosed
publicly.

RESOLUTION
==

Applying the attached patches to Linux makes the disk and network frontends
capable of protecting themselves against potentially malicious backends.  The
signaling of whether a frontend should consider a backend as potentially
malicious can be done from either the Linux kernel command line or the
toolstack.

Two different patches are provided for each Xen branch, but only the first
patch will be applied to the official Xen repository for each branch.

For the xen-unstable branch patch 1 introduces a new field to the disk and nic
configurations that allow signaling on a per-device basis whether the backend
should be trusted.  This is an ABI incompatible change, and cannot be applied
to stable branches.  Patch 2 introduces support to libxl for
libxl_{disk,nic}_backend_untrusted environment variable to be used in order to
set whether disk and network frontends should be trusted in the absence of a
per-device setting.  Patch 2 is provided as a courtesy for users of stable
branches that might come to rely on this behavior.

For the stable branches (Xen 4.16.x - Xen 4.13.x) patch 1 introduces support to
libxl for libxl_{disk,nic}_backend_untrusted environment variable to be used in
order to set whether disk and network backends should be trusted.  Patch 2
reverts patch 1 and instead provides the more fine grained per-device options
that break the libxl ABI.

Note that applying patch 2 to any of the stable releases will require a rebuild
of any consumers of the libxl library, as it introduces an ABI breakage and
hence won't be applied to the official repository stable branches.  Users of
stable releases wanting to use the functionality provided by patch 2 will need
to apply it manually.

Regardless of the combinations of patches applied, in the absence of any
environment variable mentioned above backends will be trusted by default.

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.

xsa403/xsa403-?.patch xen-unstable
xsa403/xsa403-4.16-?.patchXen 4.16.x - Xen 4.15.x
xsa403/xsa403-4.14-?.patchXen 4.14.x - Xen 4.13.x
xsa403/xsa403-linux-*.patch   Linux 5.18

$ sha256sum xsa403*/*
f28624407a3f040456ef2c52a18d8dcf486274ea082335ea38c9791646f4989c  
xsa403/xsa403-1.patch
e06451655775009ceaf460bbba65374c05203eed295ff43fc5fa32a8d390a94a  
xsa403/xsa403-2.patch
5efb8af5ed5614f5e2e8d606a9debb3503cd9e114551525826fc5a7f9de91c02  
xsa403/xsa403-4.14-1.patch
9ead8c6e4d694f3042c8d2fab4ea81619c4a9fc2aa7a0f485e9c873d927d283c  
xsa403/xsa403-4.14-2.patch
ae778d5731ae663cca32d59ed9b1be51200b85c441771a9c6657c112e9550a15  
xsa403/xsa403-4.16-1.patch
8ef7bd06f646fa72f22892d2b72ae44ff4e6c00d9817d52a71262be174862ee3  
xsa403/xsa403-4.16-2.patch
8192d0c313448d7aa12c13d1632db3bd68835c19f60c237b87548d5c528852b0  
xsa403/xsa403-linux-1.patch
4b288d3266f9396bedc7de823909aed4d1a89fe86b2edd1d625b0e32741688cf  
xsa403/xsa403-linux-2.patch
dddf68625be516f0524fe7bb439272769cf7d612e15e00ac936bc047fd182f8a  
xsa403/xsa403-linux-3.patch
4e38a50a0e5ec6e90d2fffef003f8eb93a68518f4636c15cd59568ddf1861988  
xsa403/xsa403-linux-4.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of patches or mitigations is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations 

Xen Security Advisory 406 v3 (CVE-2022-33744) - Arm guests can cause Dom0 DoS via PV devices

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-33744 / XSA-406
   version 3

 Arm guests can cause Dom0 DoS via PV devices

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

When mapping pages of guests on Arm, dom0 is using an rbtree to keep
track of the foreign mappings.

Updating of that rbtree is not always done completely with the related
lock held, resulting in a small race window, which can be used by
unprivileged guests via PV devices to cause inconsistencies of the
rbtree. These inconsistencies can lead to Denial of Service (DoS) of
dom0, e.g. by causing crashes or the inability to perform further
mappings of other guests' memory pages.

IMPACT
==

A guest performing multiple I/Os of PV devices in parallel can cause
DoS of dom0 and thus of the complete host.

VULNERABLE SYSTEMS
==

Only Arm systems (32-bit and 64-bit) are vulnerable. Dom0 Linux versions
3.13 - 5.18 are vulnerable.

X86 systems are not vulnerable.

MITIGATION
==

There is no mitigation available.

CREDITS
===

This issue was discovered by Oleksandr Tyshchenko of EPAM.

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.

xsa406-linux.patch Linux 3.13 - 5.19-rc

$ sha256sum xsa406*
7a789f564b3365cade6e95d549dbbd5a8b7b5e53d09bc5a463c77dfefd5a4182  
xsa406-linux.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/4UyVfoK9kFAmLEFgEMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZwJUIAJSrSYNMQE4jo1sJFKjEJ3cHy6CymbJC94JSm2Tf
HzeMlwd7NQF3Sc2HSWQoCSI+0TiRb6bJpfZASsbL/E3b6zcm3+VxwS7HVUtvHXhN
HJYRUMN9vckUkGwWDYbgveI7uie9P7gpjwi5CEXxQf4NO9Oloyk2J5bijktzbBN2
9FIZ7zFuiSRwGtr2WRaozCSzgg4EGiPRc5eMCFMP+K0P+oRvpkE52wWo/ZOPzW8T
xocUIcvQK335ib04OCS3oqJZrRNwrvX6Vn+CifXac2WHR9tQ24VnTq1iYRrVD+5x
kxpg4IuiNc2eD8lZCLnKEUDUj6LzWvgxKoxXgJFKXlESb0A=
=57so
-END PGP SIGNATURE-


xsa406-linux.patch
Description: Binary data

Xen Security Advisory 404 v1 (CVE-2022-21123,CVE-2022-21124,CVE-2022-21166) - x86: MMIO Stale Data vulnerabilities

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory CVE-2022-21123,CVE-2022-21124,CVE-2022-21166 / XSA-404

 x86: MMIO Stale Data vulnerabilities

ISSUE DESCRIPTION
=

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 attacker might be able to directly read or infer data from other
security contexts in the system.  This can include data belonging to
other VMs, or to Xen itself.  The degree to which an attacker can obtain
data depends on the CPU, and the system configuration.

VULNERABLE SYSTEMS
==

Systems running all versions of Xen are affected.

Only x86 processors are vulnerable.  Processors from other manufacturers
(e.g. ARM) are not believed to be vulnerable.

Only Intel based processors are affected.  Processors from other x86
manufacturers (e.g. AMD) are not believed to be vulnerable.

Please consult the Intel Security Advisory for details on the affected
processors and configurations.

Per Xen's support statement, PCI passthrough should be to trusted
domains because the overall system security depends on factors outside
of Xen's control.

As such, Xen, in a supported configuration, is not vulnerable to
DRPW/SBDR.

MITIGATION
==

All mitigations depend on functionality added in the IPU 2022.1 (May
2022) microcode release from Intel.  Consult your dom0 OS vendor.

To the best of the security team's understanding, the summary is as
follows:

Server CPUs (Xeon EP/EX, Scalable, and some Atom servers), excluding
Xeon E3 (which use the client CPU design), are potentially vulnerable to
DRPW (CVE-2022-21166).

Client CPUs (inc Xeon E3) are, furthermore, potentially vulnerable to
SBDR (CVE-2022-21123) and SBDS (CVE-2022-21125).

SBDS only affects CPUs vulnerable to MDS.  On these CPUs, there are
previously undiscovered leakage channels.  There is no change to the
existing MDS mitigations.

DRPW and SBDR only affects configurations where less privileged domains
have MMIO mappings of buggy endpoints.  Consult your hardware vendor.

In configurations where less privileged domains have MMIO access to
buggy endpoints, `spec-ctrl=unpriv-mmio` can be enabled which will cause
Xen to mitigate cross-domain fill buffer leakage, and extend SRBDS
protections to protect RNG data from leakage.

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.

The patches are still under review.  An update will be sent once they
are reviewed and the backports are done.

xsa404/xsa404-?.patch   xen-unstable

$ sha256sum xsa404*/*
18b307c2cbbd08d568e9dcb2447901d94e22ff1e3945c3436173aa693f6456fb  
xsa404/xsa404-1.patch
d6f193ad963396285e983aa1c18539f67222582711fc62105c21b71b3b53a97d  
xsa404/xsa404-2.patch
d2c123ccdf5eb9f862d6e9cb0e59045ae18799a07db149c7d90e301ca20436aa  
xsa404/xsa404-3.patch
$

NOTE CONCERNING CVE-2022-21127 / Update to SRBDS


An issue was discovered with the SRBDS microcode mitigation.  A
microcode update was released as part of Intel's IPU 2022.1 in May 2022.

Updating microcode is sufficient to fix the issue, with no extra actions
required on Xen's behalf.  Consult your dom0 OS vendor or OEM for
updated microcode.

NOTE CONCERNING CVE-2022-21180 / Undefined MMIO Hang


A related issue was discovered.  See:

  
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/undefined-mmio-hang.html

Xen is not vulnerable to UMH in supported configurations.

The only mitigation to is avoid passing impacted devices through to
untrusted guests.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmKo0Z0MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZc8cH/RFgxQ4L8OewWMxsuowpgLg8NVyYGFMBgttscBh+
ANpjRTnV4yQGpt9nNFDAcXT1c/fvWhypOiwadEtczRl5k/Q96JOKFdiAc1QR35Oj
vmbCLgO20jQ/GdTzaqKUaGBwi8GLShJvH1zMPJ2KuXk5w5uFDhj2gEiB6Kdv9+9O
4FBxQkpDzll0gs5v16ien8btKhEuZj9lNtzXZw5j4+DJD69MvQqsRPVdEt+M17Ox
XGYcpfpLeGUaIUPFTPZDcFIJnMvqPBQyt+2eaeR2ezW2ouNpxepCSPsEDlAmSZ/K
uZA0ShyJD3pfCxjc8eztyF/4zajY5EvuEtWdUZC/3zVaUec=
=4EdA
-END PGP SIGNATURE-


xsa404/xsa404-1.patch
Description: Binary data


xsa404/xsa404-2.patch
Description: Binary data


xsa404/xsa404-3.patch
Description: Binary data

Xen Security Advisory 401 v2 (CVE-2022-26362) - x86 pv: Race condition in typeref acquisition

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-26362 / XSA-401
   version 2

 x86 pv: Race condition in typeref acquisition

UPDATES IN VERSION 2


Update 4.16 and 4.15 baselines.

Public release.

ISSUE DESCRIPTION
=

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.

IMPACT
==

Malicious x86 PV guest administrators may be able to escalate privilege
so as to control the whole system.

VULNERABLE SYSTEMS
==

All versions of Xen are vulnerable.

Only x86 PV guests can trigger this vulnerability.

To exploit the vulnerability, there needs to be an undue delay at just
the wrong moment in _get_page_type().  The degree to which an x86 PV
guest can practically control this race condition is unknown.

MITIGATION
==

Not running x86 PV guests will avoid the vulnerability.

CREDITS
===

This issue was discovered by Jann Horn of Google Project Zero.

RESOLUTION
==

Applying the appropriate attached patches 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.

xsa401/xsa401-?.patch   xen-unstable
xsa401/xsa401-4.16-?.patch  Xen 4.16.x - Xen 4.14.x
xsa401/xsa401-4.13-?.patch  Xen 4.13.x

$ sha256sum xsa401* xsa401*/*
d442bc0946eaa4c325226fd0805ab81eba6a68b68cffb9b03d9552edea86b118  xsa401.meta
074b57204f828cbd004c2d024b02a41af5d5bf3547d407af27249dca95eca13a  
xsa401/xsa401-1.patch
a095b39b203d501f9c9d4974638cd4d5e2d7a18daee7a7a61e2010dea477e212  
xsa401/xsa401-2.patch
99af3efc91d2dbf4fd54cc9f454b87bd76edbc85abd1a20bdad0bd22acabf466  
xsa401/xsa401-4.13-1.patch
bb997094052edbbbdd0dc9f3a0454508eb737556e2449ec6a0bc649deb921e4f  
xsa401/xsa401-4.13-2.patch
d336b31cb91466942e4fb8b44783bb2f0be4995076e70e0e78cdf992147cf72a  
xsa401/xsa401-4.16-1.patch
b380a76d67957b602ff3c9a3faaa4d9b422834d6ee3ab72432a6d07ddbc6  
xsa401/xsa401-4.16-2.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/4UyVfoK9kFAmKh4lsMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZcoAH/ijbKKkQet6frag9HVfDHZtcb6N7yIxMUioVOu9t
tNhg4LdJJnnrCqXmJdXygZTYwIZufQGQOxMR3b66+6MJyz0JIL7XExqnLJs6mDsO
GFcvsxoGLYSdsBTVtGQgLpEPxwgkblKUQuwokz3K3kdxcHJmJceZitvaDdrycw8M
kRZ22qHUbFWTSOKZNe5t9t0x/4xwdyM4dYElAmuN4Ej1cQhhXG/Gbl+acZexS+cz
TFEbIS5G/j6EgaCpBSP5XCoUn2LlyswRxBllGh0kpaLrJRH4CX3E/KHBSdPMkWoP
3HyQF3o+WYvpWUGXVaAREaR+WxlsAwmQJUxpO64O4Y4IUEY=
=UGgq
-END PGP SIGNATURE-


xsa401.meta
Description: Binary data


xsa401/xsa401-1.patch
Description: Binary data


xsa401/xsa401-2.patch
Description: Binary data


xsa401/xsa401-4.13-1.patch
Description: Binary data


xsa401/xsa401-4.13-2.patch
Description: Binary data


xsa401/xsa401-4.16-1.patch
Description: Binary data


xsa401/xsa401-4.16-2.patch
Description: Binary data

Xen Security Advisory 399 v2 (CVE-2022-26357) - race in VT-d domain ID cleanup

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-26357 / XSA-399
   version 2

race in VT-d domain ID cleanup

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

Xen domain IDs are up to 15 bits wide.  VT-d hardware may allow for only
less than 15 bits to hold a domain ID associating a physical device with
a particular domain.  Therefore internally Xen domain IDs are mapped to
the smaller value range.  The cleaning up of the housekeeping structures
has a race, allowing for VT-d domain IDs to be leaked and flushes to be
bypassed.

IMPACT
==

The precise impact is system specific, but would typically be a Denial
of Service (DoS) affecting the entire host.  Privilege escalation and
information leaks cannot be ruled out.

VULNERABLE SYSTEMS
==

Xen versions 4.11 through 4.16 are vulnerable.  Xen versions 4.10 and
earlier are not vulnerable.

Only x86 systems with VT-d IOMMU hardware are vulnerable.  Arm systems
as well as x86 systems without VT-d hardware or without any IOMMUs in
use are not vulnerable.

Only x86 guests which have physical devices passed through to them can
leverage the vulnerability.

MITIGATION
==

Not passing through physical devices to untrusted guests will avoid
the vulnerability.

CREDITS
===

This issue was discovered by Jan Beulich of SUSE.

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.

xsa399.patch   xen-unstable
xsa399-4.16.patch  Xen 4.16.x - Xen 4.13.x
xsa399-4.12.patch  Xen 4.12.x

$ sha256sum xsa399*
53b9745564eb21f70dbb7bd7194ff3518f29cd9715c68e9dd7eff25812968019  xsa399.patch
16c3327a60d8ab6c3524f10f57d63efaf2e3e54b807bc285a749cd1a94392a30  
xsa399-4.12.patch
79d0f5a0442dec0a806d77a722a1d2c04793572fe0b564bf86dcd1c6d992a679  
xsa399-4.16.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.

HOWEVER, deployment of the mitigation is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List).  Specifically, deployment on public cloud systems
is NOT permitted.

This is because removal of pass-through devices or their replacement by
emulated devices is a guest visible configuration change, which may lead
to re-discovery of the issue.

Deployment of this mitigation is permitted only AFTER the embargo ends.

AND: 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/4UyVfoK9kFAmJMJDcMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZpo8H/AqiAS0l5WJWl00bTQ4Q69REzd83m9Y3+UnUqRaf
JUFWo4R1m4V2zJlq0E3TR/2ZS1RkXFJxlmXQyzueFmDEvMV2oKB0ids5ta1oUO2E
eiQxdSFbTLrLnhI+4IxbTHHy+ovSHT/SKPeo1Zd1tXHfZ35g1OgGTYHHqj7RKJHp
SyZT4iuAKjIr61M4NBKJcycpfRidlXEDvAotDX3jBQ06t3vgs/12nwe5LzzeV2V4
sIDjpeDGNKzgT2NgLP2b+XMEUg1259iWb19tS3PPNJaLKSvQqTBOFjK+sqh7ACXV
v6ph2Yy0Q/ZP+N9DvCeBCPEU9A9RhmPYzobU+Lc/T85SrQ4=
=sp/Q
-END PGP SIGNATURE-


xsa399.patch
Description: Binary data


xsa399-4.12.patch
Description: Binary data


xsa399-4.16.patch
Description: Binary data

Xen Security Advisory 397 v2 (CVE-2022-26356) - Racy interactions between dirty vram tracking and paging log dirty hypercalls

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-26356 / XSA-397
   version 2

 Racy interactions between dirty vram tracking and paging log dirty hypercalls

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

Activation of log dirty mode done by XEN_DMOP_track_dirty_vram (was named
HVMOP_track_dirty_vram before Xen 4.9) is racy with ongoing log dirty
hypercalls.  A suitably timed call to XEN_DMOP_track_dirty_vram can enable
log dirty while another CPU is still in the process of tearing down the
structures related to a previously enabled log dirty mode
(XEN_DOMCTL_SHADOW_OP_OFF).  This is due to lack of mutually exclusive locking
between both operations and can lead to entries being added in already freed
slots, resulting in a memory leak.

IMPACT
==

An attacker can cause Xen to leak memory, eventually leading to a Denial of
Service (DoS) affecting the entire host.

VULNERABLE SYSTEMS
==

All Xen versions from at least 4.0 onwards are vulnerable.

Only x86 systems are vulnerable.  Arm systems are not vulnerable.

Only domains controlling an x86 HVM guest using Hardware Assisted Paging (HAP)
can leverage the vulnerability.  On common deployments this is limited to
domains that run device models on behalf of guests.

MITIGATION
==

Using only PV or PVH guests and/or running HVM guests in shadow mode will avoid
the vulnerability.

CREDITS
===

This issue was discovered by Roger Pau Monné of Citrix.

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.

xsa397.patch   xen-unstable
xsa397-4.16.patch  Xen 4.16.x - Xen 4.15.x
xsa397-4.14.patch  Xen 4.14.x - Xen 4.13.x
xsa397-4.12.patch  Xen 4.12.x

$ sha256sum xsa397*
49c663e2bb9131dbc2488e12487f79bdf0dafd51a32413cbf3964e39d8779cae  xsa397.patch
24f95f47b79739c9cb5b9110137c802989356c82d0aa27963b5ac7e33f667285  
xsa397-4.12.patch
9af14f90ba10d074425eb6072a6c648082c92c1cf8b6f881f57ed2fc13d6e49d  
xsa397-4.14.patch
ff5dd3b7a8dbf349c3b832b7916322c0296fa59c7f9cd2ba30858989add5f65c  
xsa397-4.16.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches 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 (except to other members of the
predisclosure list) or deployment of mitigations is prohibited.

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/4UyVfoK9kFAmJMJDEMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZOUMH/RRZ8aMaoywqTV38SeTFne2tFT5jnWPPXR1ZGCvh
825hmSqzcYUaILbWFruUfT2PdpGoU9Eprz3xWXBDwgsUEGvKt7ZhGoWvxzXASlDh
cPRh/XwQVEEYsB1cRSk/GoLxLCQEV8oGNpmAcjEM4K1dG0VbVaRD0W2thNCmyPcv
d7aTkAdD2IE8NU4hX8YGN6v+UCkjrgzL0AF/hff9CMj7Sn/wBRrdStLT0LDZU20c
G/5+9nsOAVM7EwrzImI5Lx9KELyHwl37XUPffbftyTLUofdHJ5PK40J1tNIRS/RW
YYvs2alF7ng7LlwB/Go8gtn4XRx6xZidceYrUk22oB4JBqo=
=Fje3
-END PGP SIGNATURE-


xsa397.patch
Description: Binary data


xsa397-4.12.patch
Description: Binary data


xsa397-4.14.patch
Description: Binary data


xsa397-4.16.patch
Description: Binary data

Xen Security Advisory 396 v3 (CVE-2022-23036,CVE-2022-23037,CVE-2022-23038,CVE-2022-23039,CVE-2022-23040,CVE-2022-23041,CVE-2022-23042) - Linux PV device frontends vulnerable to attacks by backends

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory 
CVE-2022-23036,CVE-2022-23037,CVE-2022-23038,CVE-2022-23039,CVE-2022-23040,CVE-2022-23041,CVE-2022-23042
 / XSA-396
 version 3

  Linux PV device frontends vulnerable to attacks by backends

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

Several Linux PV device frontends are using the grant table interfaces
for removing access rights of the backends in ways being subject to
race conditions, resulting in potential data leaks, data corruption
by malicious backends, and denial of service triggered by malicious
backends:

blkfront, netfront, scsifront and the gntalloc driver are testing
whether a grant reference is still in use. If this is not the case,
they assume that a following removal of the granted access will always
succeed, which is not true in case the backend has mapped the granted
page between those two operations. As a result the backend can keep
access to the memory page of the guest no matter how the page will be
used after the frontend I/O has finished. The xenbus driver has a
similar problem, as it doesn't check the success of removing the
granted access of a shared ring buffer.
blkfront: CVE-2022-23036
netfront: CVE-2022-23037
scsifront: CVE-2022-23038
gntalloc: CVE-2022-23039
xenbus: CVE-2022-23040

blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront,
and pvcalls are using a functionality to delay freeing a grant reference
until it is no longer in use, but the freeing of the related data page
is not synchronized with dropping the granted access. As a result the
backend can keep access to the memory page even after it has been freed
and then re-used for a different purpose.
CVE-2022-23041


netfront will fail a BUG_ON() assertion if it fails to revoke access in
the rx path. This will result in a Denial of Service (DoS) situation of
the guest which can be triggered by the backend.
CVE-2022-23042

IMPACT
==

Due to race conditions and missing tests of return codes in the Linux
PV device frontend drivers a malicious backend could gain access (read
and write) to memory pages it shouldn't have, or it could directly
trigger Denial of Service (DoS) in the guest.

VULNERABLE SYSTEMS
==

All Linux guests using PV devices are vulnerable in case potentially
malicious PV device backends are being used.

MITIGATION
==

There is no mitigation available other than not using PV devices in case
a backend is suspected to be potentially malicious.

RESOLUTION
==

Applying the attached patches resolves this issue.

xsa396-linux-*.patch   Linux upstream

$ sha256sum xsa396*
d21d2d2c499d8e7c1cbc347d9df118b27af7d7c9ca5c104fcf1fef022ba6b92d  
xsa396-linux-01.patch
c150c7873497b4d9807fcfe2a4a4831b033597db3d4c3dfaada1e647db1395fa  
xsa396-linux-02.patch
6439ac16b6d6b29d6773d00895776a7392a321caa01f569062c4140d3d66167c  
xsa396-linux-03.patch
2cc0b472514be47690ef257ab8d296bbec1827d18f98e1f1bbbfea53aafec78c  
xsa396-linux-04.patch
cd6b6e65fe9915f98b04363bf1f22ddbd7c448215d52858ad1a2318bb1f034c8  
xsa396-linux-05.patch
353e4de564897ad07120b17aa7a6a22b90fba6e65f39c20fe561ba06405656f3  
xsa396-linux-06.patch
bf923c3bc92a908215d5ade016d27f56d1e445da88b04e1e1d4530ea5b139be3  
xsa396-linux-07.patch
0a306ed20e4259e2a3583bfab14672a245bd33b24e95e5df8bfc30a25f7e18c6  
xsa396-linux-08.patch
130b8305ba8c10e2942553078b845899ef79c5570692a499569a526b1e39d4fe  
xsa396-linux-09.patch
1f70bdc0a5c1ff1b538d8cbec17e99af5888669f3a33ad8a02d2026719ad4bc9  
xsa396-linux-10.patch
48fd782c6b0b705ccb59885d0e1562873f44478ea87f705f08ce18336bc19257  
xsa396-linux-11.patch
d720350d36f7434e2cad1cb0ae0ed48776ad870a7b1e61cdd08d80fb4a787d59  
xsa396-linux-12.patch
$

CREDITS
===

This issue was discovered by Demi Marie Obenour and Simon Gaiser of
Invisible Things Lab.

DEPLOYMENT DURING EMBARGO
=

Deployment of patches or mitigations is NOT permitted (except where
all the affected VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List).  Specifically, deployment on public cloud systems
is NOT permitted.

This is because the patches need to be applied in the affected guests.
Switching from PV to non-PV devices is observable by the guests and has
usually a bad performance impact.

Deployment is permitted only AFTER the embargo ends.


(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+MiLBRf

Xen Security Advisory 395 v2 (CVE-2022-23035) - Insufficient cleanup of passed-through device IRQs

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-23035 / XSA-395
   version 2

  Insufficient cleanup of passed-through device IRQs

UPDATES IN VERSION 2


Adjust patch subject.

Public release.

ISSUE DESCRIPTION
=

The management of IRQs associated with physical devices exposed to x86
HVM guests involves an iterative operation in particular when cleaning
up after the guest's use of the device.  In the case where an interrupt
is not quiescent yet at the time this cleanup gets invoked, the cleanup
attempt may be scheduled to be retried.  When multiple interrupts are
involved, this scheduling of a retry may get erroneously skipped.  At
the same time pointers may get cleared (resulting in a de-reference of
NULL) and freed (resulting in a use-after-free), while other code would
continue to assume them to be valid.

IMPACT
==

The precise impact is system specific, but would typically be a Denial
of Service (DoS) affecting the entire host.  Privilege escalation and
information leaks cannot be ruled out.

VULNERABLE SYSTEMS
==

Xen versions 4.6 and later are vulnerable.  Xen versions 4.5 and earlier
are not vulnerable.

Only x86 HVM guests with one or more passed-through physical devices
using (together) multiple physical interupts can leverage the
vulnerability.  x86 PV guests cannot leverage the vulnerability.  x86
HVM guests without passed-through devices or with a passed-through
device using just a single physical interrupt also cannot leverage the
vulnerability.  Device pass-through is unsupported for x86 PVH guests
and all Arm guests.

MITIGATION
==

There is no mitigation (other than not passing through to x86 HVM guests
PCI devices with, overall, more than a single physical interrupt).

CREDITS
===

This issue was discovered by Julien Grall of Amazon.

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.

xsa395.patch   xen-unstable - Xen 4.15.x
xsa395-4.14.patch  Xen 4.14.x - Xen 4.12.x

$ sha256sum xsa395*
f460be598b936bb5cfb9276787f2f21d90b029d1fe10dabd572ae50f84a1124d  xsa395.meta
295b876c52cf5efe19150757275da3d154beb72ac2d7be267e16c9262e410de3  xsa395.patch
5697f3137e0a202744f31b1c6cbcfa459d8fa9b4b68be59561b78c40fe1233c5  
xsa395-4.14.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/4UyVfoK9kFAmHv39QMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZhowIAIZYZq4efyEAP5rB3zX4yRel2GNz+2Dpjok4PExB
uSOrPaH5dDILhNdVJNG48MckDe0dMDsn3OGr1I6lbxcV1TWR1JFrBQoxeUnwdiEf
GjeTni0hhefan3IEEd5HUDInQgf9oI7fUcgEdVAoIV87BQdlK0ofjJ3TggSrr8jl
pL5dmIh4OICD6YttR11Of1vhPY2WhZQb2xgSxzEQbDeY8k3JaRWy8mYwwxPD0HXn
+hmLK59ZhkJd5Sk8AxttRUTEsl6nKESrUz3vv/vFInV5Go+35AElL//gQNgOOTAS
nljLLtJdfHSuRy459Sw/lm4mwQ9zkfOFH6B+M6efSkHMyoE=
=Iv+w
-END PGP SIGNATURE-


xsa395.meta
Description: Binary data


xsa395.patch
Description: Binary data


xsa395-4.14.patch
Description: Binary data

Xen Security Advisory 394 v3 (CVE-2022-23034) - A PV guest could DoS Xen while unmapping a grant

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-23034 / XSA-394
   version 3

   A PV guest could DoS Xen while unmapping a grant

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

To address XSA-380, reference counting was introduced for grant
mappings for the case where a PV guest would have the IOMMU enabled. PV
guests can request two forms of mappings.  When both are in use for any
individual mapping, unmapping of such a mapping can be requested in two
steps.  The reference count for such a mapping would then mistakenly be
decremented twice.  Underflow of the counters gets detected, resulting
in the triggering of a hypervisor bug check.

IMPACT
==

Malicious guest kernels may be able to mount a Denial of Service (DoS)
attack affecting the entire system.

VULNERABLE SYSTEMS
==

All Xen versions from at least 3.2 onwards are vulnerable in principle,
if they have the XSA-380 fixes applied.

Only x86 systems are vulnerable.  Arm systems are not vulnerable.

Only x86 PV guests with access to PCI devices can leverage the
vulnerability.  x86 HVM and PVH guests, as well as PV guests without
access to PCI devices, cannot leverage the vulnerability.

Additionally from Xen 4.13 onwards x86 PV guests can leverage this
vulnerability only when being granted access to pages owned by another
domain.

MITIGATION
==

Not running PV guests will avoid the vulnerability.

For Xen 4.12 and older not passing through PCI devices to PV guests will
avoid the vulnerability.

For Xen 4.13 and newer not enabling PCI device pass-through for PV
guests will avoid the vulnerability.  This can be achieved via omitting
any "passthrough=..." and "pci=..." settings from xl guest configuration
files, or by setting "passthrough=disabled" there.

- From Xen 4.13 onwards, XSM SILO can be available as a security policy
designed to permit guests to only be able to communicate with Dom0.
Dom0 does not normally offer its pages for guests to map, which means
the use of SILO mode normally mitigates the vulnerability.

CREDITS
===

This issue was discovered by Julien Grall of Amazon.

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.

xsa394.patch   xen-unstable - Xen 4.13.x
xsa394-4.12.patch  Xen 4.12.x

$ sha256sum xsa394*
93f4d3b58d49ba239115753c9905b7c3720b438c48ef8fb701f15081aa317159  xsa394.meta
f2a3420e8d3eb1cf728f90d3c352ace0d3c67f7933201ce9b784d63afaeaa179  xsa394.patch
ee93797546ac9e82f98211366f9acc72b0d5ab7ef73840c2acd2bb1439ca  
xsa394-4.12.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches described above (or others which are
substantially similar) is permitted during the embargo, even on public-
facing systems with untrusted guest users and administrators.

HOWEVER, deployment of the mitigations described above is NOT permitted
during the embargo on public-facing systems with untrusted guest users
and administrators.  This is because such a configuration change is
recognizable by the affected guests.

AND: 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/4UyVfoK9kFAmHv39IMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZfCYH/iZn73/JRTKI7B+9v2fW6v/k1IcVhpu+N4+TuRhh
Al5igmiTJLU3LcHM/H2KScgtnSwEKfCyddY1Gt3MZ+5lBDwR8elRkPdqn+P7xfol
4D5NgnEJDAYUWwJZOFn0qWfqNDnDkAvuKpm1zmv8RE0Xmw6a74Fvbfvi8PCuN9CO
zdippi5r5FlzFU7Q5MoWmOhmvVe3Fg7tGs4GXIyVUYkpDYyBGEWBo6rcoQ5aDvir
g8T0P1Y8XKCVvYM9SOdKWENppam0uIh00Mm+QDjQNaXD4I3DCDXLXkT7OGImZglr
MW8z5iNFjd0iXxFqTVBe1omxUhLC1xcB1fNySjd3zpt3RfA=
=mIA+
-END PGP SIGNATURE-


xsa394.meta
Description: Binary data


xsa394.patch
Description: Binary data


xsa394-4.12.patch
Description: Binary data

Xen Security Advisory 393 v2 (CVE-2022-23033) - arm: guest_physmap_remove_page not removing the p2m mappings

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-23033 / XSA-393
   version 2

 arm: guest_physmap_remove_page not removing the p2m mappings

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

The functions to remove one or more entries from a guest p2m pagetable
on Arm (p2m_remove_mapping, guest_physmap_remove_page, and p2m_set_entry
with mfn set to INVALID_MFN) do not actually clear the pagetable entry
if the entry doesn't have the valid bit set.  It is possible to have a
valid pagetable entry without the valid bit set when a guest operating
system uses set/way cache maintenance instructions.  For instance, a
guest issuing a set/way cache maintenance instruction, then calling the
XENMEM_decrease_reservation hypercall to give back memory pages to Xen,
might be able to retain access to those pages even after Xen started
reusing them for other purposes.

IMPACT
==

A malicious guest may be able to access Xen and other domains' memory.
This could cause information leaks, host or domain Denial of Service
(DoS), and privilege escalations.

VULNERABLE SYSTEMS
==

Xen version 4.12 and newer are vulnerable.  Only Arm systems are
vulnerable.

x86 systems are not vulnerable.

MITIGATION
==

There is no known mitigation.

CREDITS
===

This issue was discovered by Dmytro Firsov of EPAM.

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.

xsa393.patch   xen-unstable - Xen 4.12.x

$ sha256sum xsa393*
ccd746687c6080ec00ba363477d8815bc648d957c21c47d3a5330be9251806a4  xsa393.meta
89e5d66c437bacbe344e72d15720c1dde98dd97fab7184c7a6ff32bb63d442dd  xsa393.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/4UyVfoK9kFAmHv38oMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZfAcH/iXwGyTpGU7AIOGNGH1VYnn3FBAVBvT4etuPXO8o
heX252xCZNh7M7qel/Db1aaAMpo2T2ypH02ZguKsojnoRAo4QrEjrnBGsCasfzqv
HFd3nMlmksNlKI9xGPxt+Q6eNuoEHgu7i/7r3J2DgiC/Pa5Hw4SMF2eat7Er5zDL
waDHFkiONa6LM/dtgZkkgps5d3B8cR4tXo3VDLzBC0pK3IysSLnacLy7FfvLg7c0
pc/qFvUXbsFjKVmG+EKu8VlCpkWONFP1FXC4pfM+rSjDdVhmc8FhFzOLzD6Tkptt
MJhgOCMrO1Z//F07l0B9C9sxVi7K5mUDSWhonUQVPCWgl2s=
=06Nb
-END PGP SIGNATURE-


xsa393.meta
Description: Binary data


xsa393.patch
Description: Binary data

Xen Security Advisory 376 v1 - frontends vulnerable to backends

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-376

   frontends vulnerable to backends

ISSUE DESCRIPTION
=

Xen offers the ability to run PV backends in regular unprivileged
guests, typically referred to as "driver domains". Running PV backends
in driver domains has one primary security advantage: if a driver domain
gets compromised, it doesn't have the privileges to take over the
system.

However, a malicious driver domain could try to attack other guests via
the PV protocol. Many PV frontends are hardened against misbehaving PV
backends, but a few of them are not and might be susceptible to Denial
of Service attacks and metadata manipulation triggered by malicious PV
backends.

IMPACT
==

Potentially malicious PV backends can cause guest DoS due to unhardened
frontends in the guests, even though this ought to have been prevented by
containing them within a driver domain.

VULNERABLE SYSTEMS
==

All guests with non-hardened frontends being serviced by potentially
malicious backends are vulnerable, even if those backends are running in a
less privileged environment. The vulnerability is not affecting the host,
but the guests using non-hardened frontends.

The console, block and net frontends have been hardened in the Linux kernel
5.16, so guests running Linux with kernel 5.16 or newer are not currently
known to be vulnerable to potentially malicious console, block or net
backends.

MITIGATION
==

In case of running potentially malicious backends, using only hardened
frontend counterparts in guests will mitigate the problem.

NOTE REGARDING LACK OF EMBARGO
==

This issue was discussed in public already.

RESOLUTION
==

The related patch is just a clarification of the security statement,
so it will NOT mitigate anything.

As there is no urgent need for this patch to go into the Xen tree it
will be posted on the xen-devel mailing list after disclosure of this
advisory.

xsa376.patch   xen-unstable

$ sha256sum xsa376*
b18551f7800d5a232bbe6953b1222ecb2c5a2058285c6fbc8d64f9b7dea2415f  xsa376.patch
$

-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmG8rFMMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZSP4H/RcD4WLHi3TuSeNspsv/+dNb906LIueHFn/3U5Pg
5Jv8EHjv16apUhzgwTfTtx0pcCCDY2aEq0rdCziGpnTKiYzEarhTuVvc5igy9U0p
jqazRTyUkU1pV6HwFIGi/kHXTUpO60amWgKoFzyM9ZMl6WKDejb2rTu6TJC5FyiE
cxpe79GC98ECw8d131EfQgRx2/TIZuVQmKZlx3vVNG1lBlMZpFX2iioR7ajCQmdu
XWt14kDYdLvmZ1UzlrOH9+jhMRIyFZ1jBZXtXEUN0zSC+aTje6nPO3WSf/gXbmNF
COUrd7JPIMEO8PvnjzM3l1PS3XltIf2wTaVr5LjmkyBoMyM=
=J4gx
-END PGP SIGNATURE-


xsa376.patch
Description: Binary data

Xen Security Advisory 392 v4 (CVE-2021-28714,CVE-2021-28715) - Guest can force Linux netback driver to hog large amounts of kernel memory

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory CVE-2021-28714,CVE-2021-28715 / XSA-392
   version 4

 Guest can force Linux netback driver to hog large amounts of kernel memory

UPDATES IN VERSION 4


Public release

ISSUE DESCRIPTION
=

Incoming data packets for a guest in the Linux kernel's netback driver
are buffered until the guest is ready to process them. There are some
measures taken for avoiding to pile up too much data, but those can
be bypassed by the guest:

There is a timeout how long the client side of an interface can stop
consuming new packets before it is assumed to have stalled, but this
timeout is rather long (60 seconds by default). Using a UDP connection
on a fast interface can easily accumulate gigabytes of data in that
time.  (CVE-2021-28715)

The timeout could even never trigger if the guest manages to have only
one free slot in its RX queue ring page and the next package would
require more than one free slot, which may be the case when using GSO,
XDP, or software hashing.  (CVE-2021-28714)

IMPACT
==

The Linux kernel's xen-netback backend driver can be forced by guests
to queue arbitrary amounts of network data, finally causing an out of
memory situation in the domain the backend is running in (usually dom0).

VULNERABLE SYSTEMS
==

All systems using the Linux kernel based network backend xen-netback
are vulnerable.

MITIGATION
==

Using another PV network backend (e.g. the qemu based "qnic" backend)
will mitigate the problem.

Using a dedicated network driver domain per guest will mitigate the
problem.

RESOLUTION
==

Applying the attached patches resolves this issue.

xsa392-linux-1.patch   Linux 5.15
xsa392-linux-2.patch   Linux 5.15

$ sha256sum xsa392*
9cf75e9919415267266a7f69ca0f3dbbafc1c55d4243cff1cb26072e28bb6e26  
xsa392-linux-1.patch
f390da9723ed03948855bfc3b112fc11bcc794fc59502d4fc5e8e358321e8684  
xsa392-linux-2.patch
$

CREDITS
===

This issue was discovered by  Jürgen Groß of SUSE.

DEPLOYMENT DURING EMBARGO
=

Deployment of the *patches* 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).


Deployment of the *mitigations* (switching to driver domains or using
a qemu based backend) is NOT permitted (except where all the affected
systems and VMs are administered and used only by organisations which
are members of the Xen Project Security Issues Predisclosure List).
Specifically, deployment of the mitigations on public cloud systems is
NOT permitted.

This is because the mitigations will result in discoverable changes of
Xenstore entries for the guest.

Deployment of the mitigations is permitted only AFTER the embargo ends.


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/4UyVfoK9kFAmG8sr8MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZQGsH/igyavZ/s8jbiANP/jVW9/4wegsqqaeaQBEyhP0o
P2wEwX30taFmT+kC/7Rf+62O2vdOJKow4C+JouCKcigDH2+nvkki/gd65cpKLkk4
BKBuSnkTkagdokTPqpQ57zKTe9R5OP4Iw8B01YCI0k08aKE782xbxLr+pac3dw2C
3tB24fdFibrzlXeMbYXM2Aw8aeSWkVjJ40XrW+Xo6k8GdgTZY9SDgTqGAv71g+bJ
liCQheGkQIQPDjFUf6S/ykRCwaQVtnHqThASPoWOwzYto3uvjyMJm74Rr9n6TLzz
WvJLQPDgObyU9RUlUXU3fgCaYgvh2ufuNreQt1d1NY01s04=
=54ve
-END PGP SIGNATURE-


xsa392-linux-1.patch
Description: Binary data


xsa392-linux-2.patch
Description: Binary data

Xen Security Advisory 391 v3 (CVE-2021-28711,CVE-2021-28712,CVE-2021-28713) - Rogue backends can cause DoS of guests via high frequency events

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory CVE-2021-28711,CVE-2021-28712,CVE-2021-28713 / XSA-391
   version 3

   Rogue backends can cause DoS of guests via high frequency events

UPDATES IN VERSION 3


Public release

ISSUE DESCRIPTION
=

Xen offers the ability to run PV backends in regular unprivileged
guests, typically referred to as "driver domains". Running PV backends
in driver domains has one primary security advantage: if a driver domain
gets compromised, it doesn't have the privileges to take over the
system.

However, a malicious driver domain could try to attack other guests via
sending events at a high frequency leading to a Denial of Service in the
guest due to trying to service interrupts for elongated amounts of time.

There are three affected backends:
 * blkfront  patch 1, CVE-2021-28711
 * netfront  patch 2, CVE-2021-28712
 * hvc_xen (console) patch 3, CVE-2021-28713

IMPACT
==

Potentially malicious PV backends can cause guest DoS due to unhardened
frontends in the guests, even though this ought to have been prevented by
containing them within a driver domain.

VULNERABLE SYSTEMS
==

All guests being serviced by potentially malicious backends are vulnerable,
even if those backends are running in a less privileged environment. The
vulnerability is not affecting the host, but the guests.

MITIGATION
==

There is no known mitigation available.

RESOLUTION
==

Applying the attached patches resolves this issue.

xsa391-linux-1.patch   Linux 5.15
xsa391-linux-2.patch   Linux 5.15
xsa391-linux-3.patch   Linux 5.15

$ sha256sum xsa391*
e55d3f15a85ff31e62a291981de89f7b0c08da807db9b2a6a2b9cbb2e29847cd  
xsa391-linux-1.patch
163fc4b9966768eb74e3bc1858a0b0254eff771898bd5f4d71806beeae0ffd2a  
xsa391-linux-2.patch
de888abe8d11d3204b4033b304cf3d66104a65956089e23f1736db682d3cedc4  
xsa391-linux-3.patch
$

CREDITS
===

This issue was discovered by Jürgen Groß of SUSE.

DEPLOYMENT DURING EMBARGO
=

Deployment of patches or mitigations is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List).  Specifically, deployment on public cloud systems
is NOT permitted.

This is because the patches need to be applied to the guests, which will
be visible by the guest administrators.

Deployment is permitted only AFTER the embargo ends.

(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/4UyVfoK9kFAmG8srwMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZz/kH/RFI60D9qJnbNmDMgtbvihwn+jeHI0ejS7en8Ojf
CL9QftZ2+YdyxjMISOHCCaWgUKQQyF/n9chF5sMMOkWRfUPL2TDPPKTmEnC9XMOq
MYIftwT0OoMAVVhrRU3FZUZtpvTeQstofOYhBGhElmeEibYU+DbjKiv4agTEE3+8
9M3cxDk3Zw9cO1/6tU3kYtPkbxVP3r6kZQSHnpRnKLbABXWJB3Y02cX09tU//mV7
2REisCWKViLcKoupYTUOQHPWOD+VFE48mwKB4D9H9t9aTyn5PVjH/jVhiGrqbbic
ia8a0AKi5F9l8xIKha81+TGIbjCY+HCuLbaShRDnaU9/2Qc=
=wKo2
-END PGP SIGNATURE-


xsa391-linux-1.patch
Description: Binary data


xsa391-linux-2.patch
Description: Binary data


xsa391-linux-3.patch
Description: Binary data

Xen Security Advisory 388 v3 (CVE-2021-28704,CVE-2021-28707,CVE-2021-28708) - PoD operations on misaligned GFNs

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory CVE-2021-28704,CVE-2021-28707,CVE-2021-28708 / XSA-388
   version 3

   PoD operations on misaligned GFNs

UPDATES IN VERSION 3


Correct affected versions range.

Add CVE numbers to patches.

Public release.

ISSUE DESCRIPTION
=

x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode,
to provide a way for them to later easily have more memory assigned.

Guests are permitted to control certain P2M aspects of individual
pages via hypercalls.  These hypercalls may act on ranges of pages
specified via page orders (resulting in a power-of-2 number of pages).
The implementation of some of these hypercalls for PoD does not
enforce the base page frame number to be suitably aligned for the
specified order, yet some code involved in PoD handling actually makes
such an assumption.

These operations are XENMEM_decrease_reservation (CVE-2021-28704) and
XENMEM_populate_physmap (CVE-2021-28707), the latter usable only by
domains controlling the guest, i.e. a de-privileged qemu or a stub
domain.  (Patch 1, combining the fix to both these two issues.)

In addition handling of XENMEM_decrease_reservation can also trigger a
host crash when the specified page order is neither 4k nor 2M nor 1G
(CVE-2021-28708, patch 2).

IMPACT
==

Malicious or buggy guest kernels may be able to mount a Denial of
Service (DoS) attack affecting the entire system.  Privilege escalation
and information leaks cannot be ruled out.

VULNERABLE SYSTEMS
==

All Xen versions from 4.7 onwards are affected.  Xen versions 4.6 and
older are not affected.

Only x86 HVM and PVH guests started in populate-on-demand mode can
leverage the vulnerability.  Populate-on-demand mode is activated
when the guest's xl configuration file specifies a "maxmem" value which
is larger than the "memory" value.

MITIGATION
==

Not starting x86 HVM or PVH guests in populate-on-demand mode will avoid
the vulnerability.

CREDITS
===

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==

Applying the appropriate pair if attached patches 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.

xsa388-?.patch   xen-unstable
xsa388-4.15-?.patch  Xen 4.15.x
xsa388-4.14-?.patch  Xen 4.14.x - 4.12.x

$ sha256sum xsa388*
43f6647e9f7d28d22eeb98680e116b301b0e29ef63ea65c9839a5aaebd449bc4  xsa388-1.patch
64b27a8c7c02036528e00a3070e27e873762d68f4ea1504e906aaf2ddc1c06be  xsa388-2.patch
6917267482101a3f8f1d13905e14994344a0af81370c7a2b92275fb176b321a0  
xsa388-4.14-1.patch
d5886e046c69f34f98f7e1fc6ffcc36d92f8fc79242b9dc88412c39aa79b4ac3  
xsa388-4.14-2.patch
fbe6af409447edc2318940d7c4bc0861a236d40db037166608fc09fa57ef54b1  
xsa388-4.15-1.patch
c828d735aaa3f430ccef314bf27519cd6a5f4daaa79e1c493dc47e42ab09ec9f  
xsa388-4.15-2.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches described above (or others which are
substantially similar) is permitted during the embargo, even on public-
facing systems with untrusted guest users and administrators.

HOWEVER, deployment of the mitigation described above is NOT permitted
during the embargo on public-facing systems with untrusted guest users
and administrators.  This is because such a configuration change is
recognizable by the affected guests.

AND: 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/4UyVfoK9kFAmGc2jkMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZROMIALJsptV0nV8H5/nCLUWld3mKjAeb/+N20ul9NEwn
rUwIGGGzyrKZQdAljno+9y9o5pM8+BC+aTBwYhmxEWsHm1kodTD+YnJYf8uNW/CW
uhTJp/ZB5EsWhTFHF7YoKbPG0on4KIsy0TgoUug7bv+l2zEny9gfknsj8jdp3qCy
aFv1Bb2PzRh462qVHI3f27Ee8bn7GfErouuLppmDpCva19D3bhUXQ5PhxFB+oqsI
bww4VKUo0nxZftYhpbInWm34dajEIXK7jy5Z/CUPgCj2sTOHHBv7+5JJdw0umn/A
lJ2Ta1u03sdC9JWbat4qjvdVgK9L9vT+jWsfcwk02qq+XSU=
=uSRt
-END PGP SIGNATURE-


xsa388-1.patch
Description: Binary data


xsa388-2.patch
Description: Binary data


xsa388-4.14-1.patch
Description: Binary data


xsa388-4.14-

Xen Security Advisory 385 v2 (CVE-2021-28706) - guests may exceed their designated memory limit

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28706 / XSA-385
   version 2

 guests may exceed their designated memory limit

UPDATES IN VERSION 2


Add CVE numbers to patches.

Public release.

ISSUE DESCRIPTION
=

When a guest is permitted to have close to 16TiB of memory, it may be
able to issue hypercalls to increase its memory allocation beyond the
administrator established limit.  This is a result of a calculation
done with 32-bit precision, which may overflow.  It would then only
be the overflowed (and hence small) number which gets compared against
the established upper bound.

IMPACT
==

A guest may be able too allocate unbounded amounts of memory to itself.
This may result in a Denial of Service (DoS) affecting the entire host.

VULNERABLE SYSTEMS
==

All Xen versions from at least 3.2 onwards are affected.

On x86, only Xen builds with the BIGMEM configuration option enabled are
affected.  (This option is off by default.)

Only hosts with more than 16 TiB of memory are affected.

MITIGATION
==

Setting the maximum amount of memory a guest may allocate to strictly
less than 1023 GiB will avoid the vulnerability.

CREDITS
===

This issue was discovered by Julien Grall of Amazon.

RESOLUTION
==

Applying the appropriate first attached patch resolves this specific
issue.  The second patch in addition documents altered support status of
Xen on huge memory systems.

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.

xsa385-?.patch   xen-unstable
xsa385-4.15.patchXen 4.15.x - 4.14.x
xsa385-4.13.patchXen 4.13.x
xsa385-4.12.patchXen 4.12.x

$ sha256sum xsa385*
b278902e293730a117605200910180bb842cf95db4bdedfd54b42b7314041d8c  xsa385-1.patch
46a5ccfbb763b857f6cd0df46a9b7eed155b9de399ca4c68c9925faf4d1d9adb  xsa385-2.patch
69ebe63dc7dca71f74260af19205a6387be56c7dc67b97fa7695ab1acd3c4da4  
xsa385-4.12.patch
858eaad715e7cc62c4ab9784360f4ec77df70b2636b0755afe780d5c618cf9b4  
xsa385-4.13.patch
831e86c3adfec532b1a48a0b967b7c58c37db3733aee8d78216eb9d535b34f12  
xsa385-4.15.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches described above (or others which are
substantially similar) is permitted during the embargo, even on public-
facing systems with untrusted guest users and administrators.

HOWEVER, deployment of the mitigation described above is NOT permitted
during the embargo on public-facing systems with untrusted guest users
and administrators.  This is because such a configuration change is
recognizable by the affected guests.

AND: 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/4UyVfoK9kFAmGc2jYMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZEd4IAMwrHHAqFvSHgZ8Uw+DzMeT54db9nowudP9i/kYy
+KobbVlGkxwLAU3mvh5lRkOLYzoIonrcA99cajZQNIcOKt3Mfi/8qzGGUN+hWZvh
6EZo3m7+7vx9mhtAeDBUbjkcZBLiVyxRAWALMS67ScBEX9lZTvbyj9nGkdQJmmfR
pKt98z2Da2uR9YF521KWobuPYC0AFXujYBoavaTQpU/M8SiM+Wp1A2Fc6ZG+9ZKo
frMeqFbHvwj94Hbqpn6CoLu2d/XnykMvttuLlqCKTccQc3puHXdQRz14W8IxxGYx
gqYaIShZCFw/bUCu8mYHroDUlELJI3PIWQ1nJxy02bd5+N0=
=7E6A
-END PGP SIGNATURE-


xsa385-1.patch
Description: Binary data


xsa385-2.patch
Description: Binary data


xsa385-4.12.patch
Description: Binary data


xsa385-4.13.patch
Description: Binary data


xsa385-4.15.patch
Description: Binary data

Xen Security Advisory 387 v2 (CVE-2021-28703) - grant table v2 status pages may remain accessible after de-allocation (take two)

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28703 / XSA-387
   version 2

 grant table v2 status pages may remain accessible after de-allocation (take 
two)

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

Guest get permitted access to certain Xen-owned pages of memory.  The
majority of such pages remain allocated / associated with a guest for
its entire lifetime.  Grant table v2 status pages, however, get
de-allocated when a guest switched (back) from v2 to v1.  The freeing
of such pages requires that the hypervisor know where in the guest
these pages were mapped.  The hypervisor tracks only one use within
guest space, but racing requests from the guest to insert mappings of
these pages may result in any of them to become mapped in multiple
locations.  Upon switching back from v2 to v1, the guest would then
retain access to a page that was freed and perhaps re-used for other
purposes.

This bug was fortuitously fixed by code cleanup in Xen 4.14, and
backported to security-supported Xen branches as a prerequisite of the
fix for XSA-378.

IMPACT
==

A malicious guest may be able to elevate its privileges to that of the
host, cause host or guest Denial of Service (DoS), or cause information
leaks.

VULNERABLE SYSTEMS
==

All Xen branches up to and including 4.13 are vulnerable,
but only if the patches for XSA-378 have not been applied.

Xen versions 4.13.4, 4.14.x and 4.15.x are not affected.

Only x86 HMV and PVH guests permitted to use grant table version 2
interfaces can leverage this vulnerability.  x86 PV guests cannot
leverage this vulnerability.  On Arm, grant table v2 use is explicitly
unsupported.

MITIGATION
==

Running only PV guests will avoid this vulnerability.

Suppressing use of grant table v2 interfaces for HVM or PVH guests will
also avoid this vulnerability.

CREDITS
===

This issue was discovered by Patryk Balicki and Julien Grall of Amazon.

RESOLUTION
==

Applying the following patch resolves the issue:
  x86/p2m: don't assert that the passed in MFN matches for a remove

This patch was supplied with XSA-378, as one of 378's prerequisites.
The fix has already been applied to Xen stable branches as follows:

c65ea16dbcafbe4fe21693b18f8c2a3c5d14600e   in Xen 4.14.x, 4.15.x
f50fbddbae81fcccae56d27317bd71cc0e678ba2   in Xen 4.13.4
d44643199c96ac22491ae002d3bcd1c989b95ea4   in xen.git#stable-4.12
66f400c71d12fe8adfb895984b14f2941e8cb6ce   in xen.git#stable-4.11

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/4UyVfoK9kFAmGc2jgMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZlWUIAJ4bU9n2q9A4sqhiW0xJOCI4MIdwV2ym6xziP9iN
e5sg0u3gdp94M1vLf//8h7julxLXgdJd10HWWpJkfRQcsfz3E1ul1O+mAsoHxJwI
/qGl1Xis7AkDFjrPXthJUKh/DNgi8F1Rok7XDbfFznk34v4g6anh4JDfqJIUwIFQ
l2s6qIOc2PjvmrJMXEboT1wEUADZNtChIqOL7Ibre9Zz6/mdr0FjPfPvLAqfvf9m
aLaMElJMRx5iTEUG7qCYXUn8oKLbWNTv88yceudE7QZl3/zv/UnEL8nvBZWs/Gkx
UbrC6wkNFUSpF/ngexvzsSE/SrfMYYaUPfIciyuxvuosGJY=
=DmKh
-END PGP SIGNATURE-

Xen Security Advisory 389 v3 (CVE-2021-28705,CVE-2021-28709) - issues with partially successful P2M updates on x86

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory CVE-2021-28705,CVE-2021-28709 / XSA-389
   version 3

  issues with partially successful P2M updates on x86

UPDATES IN VERSION 3


Add CVE numbers to patches.

Public release.

ISSUE DESCRIPTION
=

x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode,
to provide a way for them to later easily have more memory assigned.

Guests are permitted to control certain P2M aspects of individual
pages via hypercalls.  These hypercalls may act on ranges of pages
specified via page orders (resulting in a power-of-2 number of pages).
In some cases the hypervisor carries out the requests by splitting
them into smaller chunks.  Error handling in certain PoD cases has
been insufficient in that in particular partial success of some
operations was not properly accounted for.

There are two code paths affected - page removal (CVE-2021-28705) and
insertion of new pages (CVE-2021-28709).  (We provide one patch which
combines the fix to both issues.)

IMPACT
==

Malicious or buggy guest kernels may be able to mount a Denial of
Service (DoS) attack affecting the entire system.  Privilege escalation
and information leaks cannot be ruled out.

VULNERABLE SYSTEMS
==

All Xen versions from 3.4 onwards are affected.  Xen versions 3.3 and
older are believed to not be affected.

Only x86 HVM and PVH guests started in populate-on-demand mode are
believed to be able to leverage the vulnerability.  Populate-on-demand
mode is activated when the guest's xl configuration file specifies a
"maxmem" value which is larger than the "memory" value.

MITIGATION
==

Not starting x86 HVM or PVH guests in populate-on-demand mode is
believed to allow avoiding the vulnerability.

CREDITS
===

This issue was discovered by Jan Beulich of SUSE.

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.

xsa389.patch   xen-unstable
xsa389-4.15.patch  Xen 4.15.x
xsa389-4.14.patch  Xen 4.14.x
xsa389-4.13.patch  Xen 4.13.x
xsa389-4.12.patch  Xen 4.12.x

$ sha256sum xsa389*
c00f5b07594a6459bdd6f7334acc373bc3b0c14a5b0e444ec624ac60f857fc6f  xsa389.patch
bf0d66623c3239e334a17332035be5d7c7e33cfdd7f04f9b385f70ce8fa92752  
xsa389-4.12.patch
2737affcf1e0fae5d412067ea8c7fe1cc91a28fa22f3f7e97a502cbd032582cc  
xsa389-4.13.patch
b243284679b32ab8c817a2e41562d8694d9781fa8096c268bb41b0cd91684baa  
xsa389-4.14.patch
0a213e141089fe7808eae067b3c43beed6c7d5887fa4c901e8f9352618788e5a  
xsa389-4.15.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches described above (or others which are
substantially similar) is permitted during the embargo, even on public-
facing systems with untrusted guest users and administrators.

HOWEVER, deployment of the mitigation described above is NOT permitted
during the embargo on public-facing systems with untrusted guest users
and administrators.  This is because such a configuration change is
recognizable by the affected guests.

AND: 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/4UyVfoK9kFAmGc2jkMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZkOAIAInsof4UP5VTDcLtiwCvGskCXZT0SwbJ5OKbmxG7
RmPJg+R5sy89aHyJ4BP4eRfgrfbG35qBSCB5zLHy2FR3oioRmDz3y4KAFP3hXJRc
B0hSNM9Al9nEfdt0YQeVxt297X0Ouz/bihLoHXKOTZ2AqKcafu9GRIdK0Kcj1v49
azcW1ndfAkIEYDGvtcdZDXYT3CyjLusQme3pweohZGwcQW6UYg7DhRKl0KPQZP/L
paQZd60walNWgDcV7qfMnWit2jYxF4AptLW8c+KFig7qorLE5z9Xj7AIJ6kGriry
fnwy/DE2xRr4IxWk/FsJgDxeAS6mv3KQ2Mpgx2bRAD0jB6I=
=3P7k
-END PGP SIGNATURE-


xsa389.patch
Description: Binary data


xsa389-4.12.patch
Description: Binary data


xsa389-4.13.patch
Description: Binary data


xsa389-4.14.patch
Description: Binary data


xsa389-4.15.patch
Description: Binary data

Xen Security Advisory 390 v1 (CVE-2021-28710) - certain VT-d IOMMUs may not work in shared page table mode

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28710 / XSA-390

  certain VT-d IOMMUs may not work in shared page table mode

ISSUE DESCRIPTION
=

For efficiency reasons, address translation control structures (page
tables) may (and, on suitable hardware, by default will) be shared
between CPUs, for second-level translation (EPT), and IOMMUs.  These
page tables are presently set up to always be 4 levels deep.  However,
an IOMMU may require the use of just 3 page table levels.  In such a
configuration the lop level table needs to be stripped before
inserting the root table's address into the hardware pagetable base
register.  When sharing page tables, Xen erroneously skipped this
stripping.  Consequently, the guest is able to write to leaf page
table entries.

IMPACT
==

A malicious guest may be able to escalate its privileges to that of
the host.

VULNERABLE SYSTEMS
==

Xen version 4.15 is vulnerable.  Xen versions 4.14 and earlier are not
vulnerable.

Only x86 Intel systems with IOMMU(s) in use are affected.  Arm
systems, non-Intel x86 systems, and x86 systems without IOMMU are not
affected.

Only HVM guests with passed-through PCI devices and configured to share
IOMMU and EPT page tables are able to leverage the vulnerability on
affected hardware.  Note that page table sharing is the default
configuration on capable hardware.

Systems are only affected if the IOMMU used for a passed through
device requires the use of page tables less than 4 levels deep.  We
are informed that this is the case for some at least Ivybridge and
earlier "client" chips; additionally it might be possible for such a
situation to arise when Xen is running nested under another
hypervisor, if an (emulated) Intel IOMMU is made available to Xen.

MITIGATION
==

Suppressing the use of shared page tables avoids the vulnerability.
This can be achieved globally by passing "iommu=no-sharept" on the
hypervisor command line.  This can also be achieved on a per-guest basis
via the "passthrough=sync_pt" xl guest configuration file option.

RESOLUTION
==

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

xsa390.patch   xen-unstable - Xen 4.15.x

$ sha256sum xsa390*
34d3b59a52c79bd7f9d963ca44ee5cfee08274d49961726e81c34eeff6e6cd37  xsa390.patch
$

CREDITS
===

This issue was discovered by Jan Beulich of SUSE.

NOTE REGARDING LACK OF EMBARGO
==

This fix for issue was submitted in public before realizing the security
aspect.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmGXsGUMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZiMkH/2t+q/yAO7srnKdt1yLhOcG/tok0pdSLe5b3ayES
ZktW69wnSlQ/TeH96A64pZKxXbQpRh3cDbjn2xedCDGIOyaKuObgPY7aYfuvtOxN
/6a3P3qUf2oxm5/nS0KG6kHX69gptXupvgCPwl2i1KWARi4uMEm76N7lCe3o8fFd
s8HNfLvJ0tX6pXtOQjeQEt73fDWQ/hwKGGJctFI1hrvy01erqHDdZrYiJAO6vp8z
c9LU1o8dIQSUg2dm5GSX5DCX6xEzOh6sT53CDQ7W5gTn+SnCGr7FT1iTeXYeTFSN
EaYZVynkaxQeCXsoJO0K2o7lwwKvUrQ6GNhqdd4iOR/annY=
=P/qb
-END PGP SIGNATURE-


xsa390.patch
Description: Binary data

Xen Security Advisory 386 v2 (CVE-2021-28702) - PCI devices with RMRRs not deassigned correctly

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28702 / XSA-386
   version 2

PCI devices with RMRRs not deassigned correctly

UPDATES IN VERSION 2


Updated/corrected information about vulnerable versions.
Upstream Xen 4.12 is not affected.

There is no harm from applying the patch to an unaffected version.

ISSUE DESCRIPTION
=

Certain PCI devices in a system might be assigned Reserved Memory
Regions (specified via Reserved Memory Region Reporting, "RMRR").
These are typically used for platform tasks such as legacy USB
emulation.

If such a device is passed through to a guest, then on guest shutdown
the device is not properly deassigned.  The IOMMU configuration for
these devices which are not properly deassigned ends up pointing to a
freed data structure, including the IO Pagetables.

Subsequent DMA or interrupts from the device will have unpredictable
behaviour, ranging from IOMMU faults to memory corruption.

This bug has existed since at least Xen 4.4 But it was previously
masked by a tangentially-related misbehaviour; that misbehaviour was
corrected in f591755823a7
 IOMMU/PCI: don't let domain cleanup continue when device de-assignment failed
which was backported to supported stable branches.

IMPACT
==

Administrators of guests which have been assigned RMRR-using PCI
devices can cause denial of service and other problems, possibly
including escalation of privilege.

VULNERABLE SYSTEMS
==

For stable Xen releases: 4.13.4, 4.14.3 and 4.15.1 are vulnerable.
Other versions of Xen released by the Xen Project are not affected.

For Xen git branches: the HEADs of 4.13 and later (including
xen-unstable) were vulnerable, up until 2021-10-05 (when the patch in
this advisory was committed).  4.12 and earlier are not affected.

In detail: code that has the following patch applied, is vulnerable:
 IOMMU/PCI: don't let domain cleanup continue when device de-assignment failed
That patch is currently in upstream stable branches 4.13 onwards and
was included in the most recent stable point releases of each Xen version.
Other downstream Xen builds may be affected if that patch was backported.

Only Intel x86 systems are affected.  AMD x86 systems, and Arm
systems, are all unaffected.

Only systems using PCI passthrough are affected.  (And then, only if
the assigned devices have RMRRs, but whether a device advertises RMRRs
is not easy to discern.)

MITIGATION
==

There is no mitigation (other than not passing through PCI devices
with RMRRs to guests).

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.

xsa386.patch   xen-unstable - Xen 4.13.x

$ sha256sum xsa386*
f2f83c825e249bba9454437b48bbd8307fe7a224f56484388a67af124dfd279b  xsa386.patch
$

NOTE CONCERNING LACK OF EMBARGO
===

This issue was reported and debugged in public before the security nature
became apparent.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmFfBvkMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZY20H/jWe2XVSU6R+cOv4GbhWL5sWBv4skLZ07yq77p8i
JB9nJXdVkyHJPSkENzggGGiygiHMJFSD5cLvczJp1IbAlQKQlZt/oVG9oTWHHeqO
joabwgZ9UyNW8/beCigRo1PYdiWI7tMsLp3D/LAjE8+ZhBRjD0NKLyWK26Uw0R8A
Su5tApmlBGx0BJzQm4BUWiyog86fPoNcBkP1hRJfj1BfXRjVYB5MsaPCtMhsqBlG
CFjDJ51Wn4Esxkg22e/429MbbExIAJUZoxuOWDk/D7nQShQNBTfqci4pfcaf5E+f
Mxi32bIr/XY5LLgf0Opu5Sl2JP3s7Ik3IDlSa+wYoGIZWB4=
=Ti35
-END PGP SIGNATURE-


xsa386.patch
Description: Binary data

Xen Security Advisory 386 v1 (CVE-2021-28702) - PCI devices with RMRRs not deassigned correctly

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28702 / XSA-386

PCI devices with RMRRs not deassigned correctly

ISSUE DESCRIPTION
=

Certain PCI devices in a system might be assigned Reserved Memory
Regions (specified via Reserved Memory Region Reporting, "RMRR").
These are typically used for platform tasks such as legacy USB
emulation.

If such a device is passed through to a guest, then on guest shutdown
the device is not properly deassigned.  The IOMMU configuration for
these devices which are not properly deassigned ends up pointing to a
freed data structure, including the IO Pagetables.

Subsequent DMA or interrupts from the device will have unpredictable
behaviour, ranging from IOMMU faults to memory corruption.

IMPACT
==

Administrators of guests which have been assigned RMRR-using PCI
devices can cause denial of service and other problems, possibly
including escalation of privilege.

VULNERABLE SYSTEMS
==

All versions of Xen from at least 4.4 onwards are vulnerable.

Only Intel x86 systems are affected.  AMD x86 systems, and Arm
systems, are all unaffected.

Only systems using PCI passthrough are affected.  (And then, only if
the assigned devices have RMRRs, but whether a device advertises RMRRs
is not easy to discern.)

MITIGATION
==

There is no mitigation (other than not passing through PCI devices
with RMRRs to guests).

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.

xsa386.patch   xen-unstable - Xen 4.12.x

$ sha256sum xsa386*
f2f83c825e249bba9454437b48bbd8307fe7a224f56484388a67af124dfd279b  xsa386.patch
$

NOTE CONCERNING LACK OF EMBARGO
===

This issue was reported and debugged in public before the security nature
became apparent.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmFcnH8MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZje0H+QE5A0ZvoaJ5VupZYjAt5ynbQjVqxwxqAxZDTvP7
t3gtpsHSYgrHW+3giULxjGU0ZUGF9daO1JEIZCPCbUdIlmGqGEXdDoqtz0GrXCJJ
swQFeXQVmn9lV4KMTHO0BvGw5aZOft1VgGNrixd3vckFl7c5G8sWFdl7IU7FPDTQ
LiLMg6f1oOntBYjNZUZ2210jqct9GZ4ugURRufwZrwYIpc9H5pFnZAFHKismX/2m
x/PCdmOCeivytmUPA4k62oJVpJdysAL+31XkZz8bbAhjFsUmYBJscW2T5mSfaYIp
TaSrg9WBV+TVW7aNE2iittE2O0/YyOWfpUVh6lliECeFdd0=
=aNEo
-END PGP SIGNATURE-


xsa386.patch
Description: Binary data

Xen Security Advisory 384 v3 (CVE-2021-28701) - Another race in XENMAPSPACE_grant_table handling

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28701 / XSA-384
   version 3

Another race in XENMAPSPACE_grant_table handling

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

Guests are permitted access to certain Xen-owned pages of memory.  The
majority of such pages remain allocated / associated with a guest for
its entire lifetime.  Grant table v2 status pages, however, are
de-allocated when a guest switches (back) from v2 to v1.  Freeing
such pages requires that the hypervisor enforce that no parallel request
can result in the addition of a mapping of such a page to a guest.  That
enforcement was missing, allowing guests to retain access to pages
that were freed and perhaps re-used for other purposes.

Unfortunately, when XSA-379 was being prepared, this similar issue was
not noticed.

IMPACT
==

A malicious guest may be able to elevate its privileges to that of the
host, cause host or guest Denial of Service (DoS), or cause information
leaks.

VULNERABLE SYSTEMS
==

All Xen versions from 4.0 onwards are affected.  Xen versions 3.4 and
older are not affected.

Only x86 HVM and PVH guests permitted to use grant table version 2
interfaces can leverage this vulnerability.  x86 PV guests cannot
leverage this vulnerability.  On Arm, grant table v2 use is explicitly
unsupported.

MITIGATION
==

Running only PV guests will avoid this vulnerability.

Suppressing use of grant table v2 interfaces for HVM or PVH guests will
also avoid this vulnerability.

NOTE REGARDING EMBARGO
==

Please note that the public embargo time for this advisory is
2021-09-08, two weeks later than XSA-378,379,380,382,383.

CREDITS
===

This issue was discovered by Julien Grall of Amazon.

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.

xsa384.patch   xen-unstable - Xen 4.15.x
xsa384-4.14.patch  Xen 4.14.x - 4.12.x
xsa384-4.11.patch  Xen 4.11.x

$ sha256sum xsa384*
3bf555e8b2a37dec361b86c0b6a3f59af2e1a24e3457ed92e0cfeaa662f1663a  xsa384.patch
435b431dc77d255031832dc265a8d5aa2f13f3b1a7de497b62ac2df5ad61da90  
xsa384-4.11.patch
f98ec4c25fb122de6353eb7d9f5678dd09982f887bf201d6f178e9b647618c9a  
xsa384-4.14.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or PV-guest-only 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.

HOWEVER, distribution of updated software is prohibited (except to other
members of the predisclosure list).

ADDITIONALLY, deployment of the grant table v2 disabling mitigation
described above *is* now (following the public release of XSA-379)
permitted during the embargo on public-facing systems with untrusted
guest users and administrators.  This is because (although such a
configuration change is recognizable by the affected guests) it is a
mitigation recommended in XSA-379, so such a change would not reveal
the existence of a further problem.

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-

iQE/BAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmE4rD4MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ8S8H+ITq1u5AaK+N1wgsgztLJRh1cjFTDaLZdI0mypwV
+wPhNdw1FFH19wYDZhOJIzv3h5352YVUYs8P6HvhFWrsUaq5n4cz17wxUHch74r3
MUUU9WUdTffQrAAOSSK65yWTUewv/FglEWP55YFBDPqBJHpVWt2MMidmP6My6azK
GZAHSWU7+qNXbs4/OM+dQJyUJm6yZtAltVtVmiJdJ5bSZyqe+82zRMnS39jlkZEh
VwFnw6rdlPcYO/fNYi25bQSlXbFeruSJYK+omrrFsyd65Z4D5LyZc5CQkfRJgEt6
vMDsQR+5hrE/KXKr2mfyTx6nh0RdR8kcI2Wh017BYuLqhA==
=AEo5
-END PGP SIGNATURE-


xsa384.patch
Description: Binary data


xsa384-4.11.patch
Description: Binary data


xsa384-4.14.patch
Description: Binary data

Xen Security Advisory 380 v3 (CVE-2021-28698) - long running loops in grant table handling

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28698 / XSA-380
   version 3

  long running loops in grant table handling

UPDATES IN VERSION 3


New bugfix patch on top of the prior set.

ISSUE DESCRIPTION
=

In order to properly monitor resource use, Xen maintains information on
the grant mappings a domain may create to map grants offered by other
domains.  In the process of carrying out certain actions, Xen would
iterate over all such entries, including ones which aren't in use
anymore and some which may have been created but never used.  If the
number of entries for a given domain is large enough, this iterating of
the entire table may tie up a CPU for too long, starving other domains
or causing issues in the hypervisor itself.

Note that a domain may map its own grants, i.e. there is no need for
multiple domains to be involved here.  A pair of "cooperating" guests
may, however, cause the effects to be more severe.

IMPACT
==

Malicious or buggy guest kernels may be able to mount a Denial of
Service (DoS) attack affecting the entire system.

VULNERABLE SYSTEMS
==

All Xen versions from at least 3.2 onwards are vulnerable in principle.

Systems running with default settings are generally believed to not be
vulnerable.

MITIGATION
==

The problem can be avoided by reducing the number of grant mappings Xen
would allow guests to establish.  For example, setting
"gnttab_max_maptrack_frames=256" on the Xen command line (available
from Xen 4.5 onwards) or "max_maptrack_frames=256" in the xl domain
configurations (available from Xen 4.10 onwards) may be low enough for
all hardware Xen is able to run on.  Note that except for driver
domains, guests don't normally have a need to establish grant mappings,
i.e. they may be okay to run with "max_maptrack_frames=0" in their xl
domain configurations.

- From Xen 4.14 onwards it is also possible to alter the system wide upper
bound of the number of grant mappings Xen would allow guests to
establish by writing to the /params/gnttab_max_maptrack_frames
hypervisor file system node.  Note however that changing the value this
way will only affect guests yet to be created on the respective host.

CREDITS
===

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==

Applying the appropriate pair of attached patches 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.

To address an issue observed with some compiler versions, another patch
needs to be applied on top. This has been committed to the unstable
tree (commit hash b6da9d0414d69c2682214ee3ecf9816fcac500d0) only so far.
This patch is listed last below.

xsa380/xsa380-[12].patchxen-unstable - Xen 4.15.x
xsa380/xsa380-4.14-?.patch  Xen 4.14.x
xsa380/xsa380-4.13-?.patch  Xen 4.13.x
xsa380/xsa380-4.12-?.patch  Xen 4.12.x
xsa380/xsa380-4.11-?.patch  Xen 4.11.x
xsa380/xsa380-3.patch   Xen 4.15.x - Xen 4.11.x

$ sha256sum xsa380* xsa380*/*
3b1938277665c195f6822a1170c50a853efa6bc3dcd6b2b0b9bbb0849a57bbf6  xsa380.meta
65411a0fd05d534ed2238b259aa2877331ac0e79f2dda80b424f34fffcce108a  
xsa380/xsa380-1.patch
e6cd6d345abaad38e10d6f680fe881e874e35a7295199e5430bacd209f0b7304  
xsa380/xsa380-2.patch
1ead53a28dedb0a502a700d9ea933e89e385c1582f4790f558a11d0d39e9d374  
xsa380/xsa380-3.patch
f3b486aa99a75ab54f9e26e21a721a413f993b27dbc3e6f2fda976fe20ddbae3  
xsa380/xsa380-4.11-1.patch
96a09c05ca87fe3590064ca6d269ca47b97c732401cb593ff1068ac91009f51a  
xsa380/xsa380-4.11-2.patch
496063cd4641258e1854a77f626cdd86c866c3ed8603bdc2ff9ab709008c84a7  
xsa380/xsa380-4.12-1.patch
d850e1263e89c7a718f2cddcfb639fe4a5095a1852fc35499ed16a4075d225e5  
xsa380/xsa380-4.12-2.patch
c23d34527a2ec68015ad78cd90365e4d80bce842ce01eeaa8cd2246021a55693  
xsa380/xsa380-4.13-1.patch
bd40ce749d02f343c79325488ac1348e1c9e88e698bbad351bdb0a0d3995f3e0  
xsa380/xsa380-4.13-2.patch
9b06085f9a4b93c465563cd76fdc682ddb9dba968c214259425b234e7053a809  
xsa380/xsa380-4.14-1.patch
bf6b53880abd53b56226080d1a32839c7c8c459867104697cd76eeafc2ea382a  
xsa380/xsa380-4.14-2.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.  HOWEVER, care has to be taken to avoid restricting
guests too much, as them suddenly being unable to map grants they used
to be able to map may lead to re-discovery of the issue.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish t

Xen Security Advisory 380 v2 (CVE-2021-28698) - long running loops in grant table handling

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28698 / XSA-380
   version 2

  long running loops in grant table handling

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

In order to properly monitor resource use, Xen maintains information on
the grant mappings a domain may create to map grants offered by other
domains.  In the process of carrying out certain actions, Xen would
iterate over all such entries, including ones which aren't in use
anymore and some which may have been created but never used.  If the
number of entries for a given domain is large enough, this iterating of
the entire table may tie up a CPU for too long, starving other domains
or causing issues in the hypervisor itself.

Note that a domain may map its own grants, i.e. there is no need for
multiple domains to be involved here.  A pair of "cooperating" guests
may, however, cause the effects to be more severe.

IMPACT
==

Malicious or buggy guest kernels may be able to mount a Denial of
Service (DoS) attack affecting the entire system.

VULNERABLE SYSTEMS
==

All Xen versions from at least 3.2 onwards are vulnerable in principle.

Systems running with default settings are generally believed to not be
vulnerable.

MITIGATION
==

The problem can be avoided by reducing the number of grant mappings Xen
would allow guests to establish.  For example, setting
"gnttab_max_maptrack_frames=256" on the Xen command line (available
from Xen 4.5 onwards) or "max_maptrack_frames=256" in the xl domain
configurations (available from Xen 4.10 onwards) may be low enough for
all hardware Xen is able to run on.  Note that except for driver
domains, guests don't normally have a need to establish grant mappings,
i.e. they may be okay to run with "max_maptrack_frames=0" in their xl
domain configurations.

- From Xen 4.14 onwards it is also possible to alter the system wide upper
bound of the number of grant mappings Xen would allow guests to
establish by writing to the /params/gnttab_max_maptrack_frames
hypervisor file system node.  Note however that changing the value this
way will only affect guests yet to be created on the respective host.

CREDITS
===

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==

Applying the appropriate pair of attached patches 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.

xsa380/xsa380-?.patch   xen-unstable - Xen 4.15.x
xsa380/xsa380-4.14-?.patch  Xen 4.14.x
xsa380/xsa380-4.13-?.patch  Xen 4.13.x
xsa380/xsa380-4.12-?.patch  Xen 4.12.x
xsa380/xsa380-4.11-?.patch  Xen 4.11.x

$ sha256sum xsa380* xsa380*/*
3b1938277665c195f6822a1170c50a853efa6bc3dcd6b2b0b9bbb0849a57bbf6  xsa380.meta
65411a0fd05d534ed2238b259aa2877331ac0e79f2dda80b424f34fffcce108a  
xsa380/xsa380-1.patch
e6cd6d345abaad38e10d6f680fe881e874e35a7295199e5430bacd209f0b7304  
xsa380/xsa380-2.patch
f3b486aa99a75ab54f9e26e21a721a413f993b27dbc3e6f2fda976fe20ddbae3  
xsa380/xsa380-4.11-1.patch
96a09c05ca87fe3590064ca6d269ca47b97c732401cb593ff1068ac91009f51a  
xsa380/xsa380-4.11-2.patch
496063cd4641258e1854a77f626cdd86c866c3ed8603bdc2ff9ab709008c84a7  
xsa380/xsa380-4.12-1.patch
d850e1263e89c7a718f2cddcfb639fe4a5095a1852fc35499ed16a4075d225e5  
xsa380/xsa380-4.12-2.patch
c23d34527a2ec68015ad78cd90365e4d80bce842ce01eeaa8cd2246021a55693  
xsa380/xsa380-4.13-1.patch
bd40ce749d02f343c79325488ac1348e1c9e88e698bbad351bdb0a0d3995f3e0  
xsa380/xsa380-4.13-2.patch
9b06085f9a4b93c465563cd76fdc682ddb9dba968c214259425b234e7053a809  
xsa380/xsa380-4.14-1.patch
bf6b53880abd53b56226080d1a32839c7c8c459867104697cd76eeafc2ea382a  
xsa380/xsa380-4.14-2.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.  HOWEVER, care has to be taken to avoid restricting
guests too much, as them suddenly being unable to map grants they used
to be able to map may lead to re-discovery of the issue.

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

Xen Security Advisory 383 v2 (CVE-2021-28700) - xen/arm: No memory limit for dom0less domUs

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28700 / XSA-383
   version 2

  xen/arm: No memory limit for dom0less domUs

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

The dom0less feature allows an administrator to create multiple
unprivileged domains directly from Xen.  Unfortunately, the
memory limit from them is not set. This allow a domain to allocate
memory beyond what an administrator originally configured.

IMPACT
==

Malicious dom0less guest could drive Xen out of memory and may
result to a Denial of Service (DoS) attack affecting the entire
system.

VULNERABLE SYSTEMS
==

Only Arm systems are vulnerable. Only domains created using the
dom0less feature are affected.

Only domains created using the dom0less feature can leverage the
vulnerability.

All versions of Xen since 4.12 are vulnerable.

MITIGATION
==

There is no known mitigation.

CREDITS
===

This issue was discovered by Julien Grall of Amazon.

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.

xsa383.patch   xen-unstable - Xen 4.13.x
xsa383-4.12.patch  Xen 4.12.x

$ sha256sum xsa383*
773fe38d5d182ce43b5552fcdf6ed08c33126ed728e40d94c5050f89bfb3bd4d  xsa383.meta
cfd0632d250cc36d88269ae08e19e742c6bd07ba130c2604d51a10ba64d4e413  xsa383.patch
d18f72fa595f330fa8ed13c9412a36fba58a8baf9ad30b9fc2fd4e4533c0ee1a  
xsa383-4.12.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/4UyVfoK9kFAmEmMPYMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZmboIALCcOpac8K7jPXZ+D5S5S1kGExOHYCLDBCZ6LyPt
jUmuR3r7xnkpJmcwSqGBHF5/PR6Sug+AjiggR8WHAFYiKod7yt1NjR4dm92Jy89x
t4mpyQ2ZX7PIMOiTfxlsmzsDspBxjk9sV6Pt7w4o25MiWdmY41hEkE+qtJ0OBto0
btzbaInKko6SXZWPGGpAToKlKPnwcApe2DehGYO98xl8eUZ8Ql/1lieHjuSK60Nx
RlboPeGDZwDgDroRj8GFNGxl2hESULVof0tG3w2IXPmYoa9iTKNUnO3KFL4kAJ/p
ZWzyRuHbX9FjQXBFnJJ5pyTHrc1aYzXJCwxAoSt436aRX2c=
=NGUO
-END PGP SIGNATURE-


xsa383.meta
Description: Binary data


xsa383.patch
Description: Binary data


xsa383-4.12.patch
Description: Binary data

Xen Security Advisory 382 v2 (CVE-2021-28699) - inadequate grant-v2 status frames array bounds check

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28699 / XSA-382
   version 2

 inadequate grant-v2 status frames array bounds check

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

The v2 grant table interface separates grant attributes from grant
status.  That is, when operating in this mode, a guest has two tables.
As a result, guests also need to be able to retrieve the addresses that
the new status tracking table can be accessed through.

For 32-bit guests on x86, translation of requests has to occur because
the interface structure layouts commonly differ between 32- and 64-bit.

The translation of the request to obtain the frame numbers of the
grant status table involves translating the resulting array of frame
numbers.  Since the space used to carry out the translation is limited,
the translation layer tells the core function the capacity of the array
within translation space.  Unfortunately the core function then only
enforces array bounds to be below 8 times the specified value, and would
write past the available space if enough frame numbers needed storing.

IMPACT
==

Malicious or buggy guest kernels may be able to mount a Denial of
Service (DoS) attack affecting the entire system.  Privilege escalation
and information leaks cannot be ruled out.

VULNERABLE SYSTEMS
==

All Xen versions from 4.10 onwards are affected.  Xen versions 4.9 and
older are not affected.

Only 32-bit x86 guests permitted to use grant table version 2 interfaces
can leverage this vulnerability.  64-bit x86 guests cannot leverage this
vulnerability, but note that HVM and PVH guests are free to alter their
bitness as they see fit.  On Arm, grant table v2 use is explicitly
unsupported.

Only guests permitted to have 8177 or more grant table frames can
leverage this vulnerability.

MITIGATION
==

The problem can be avoided by not increasing too much the number of
grants Xen would allow guests to establish.  The limit is controlled by
the "gnttab_max_frames" Xen command line option and the
"max_grant_frames" xl domain configuration setting.

- From Xen 4.14 onwards it is also possible to alter the system wide upper
bound of the number of grants Xen would allow guests to establish by
writing to the /params/gnttab_max_frames hypervisor file system node.
Note however that changing the value this way will only affect guests
yet to be created on the respective host.

Suppressing use of grant table v2 interfaces for 32-bit x86 guests will
also avoid this vulnerability.

CREDITS
===

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==

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

xsa382.patch   xen-unstable - Xen 4.11.x

$ sha256sum xsa382*
1254d62c8ec2c6b45c117d1483af9a71f5de0e4142c9451dd5a75ee334219542  xsa382.meta
9e500ba2bfe36bebf27262afcb9be7b02f950aed4a7b6c1738606d5ed538c2b8  xsa382.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or grant-frames-limiting mitigation
described above (or others which are substantially similar) is permitted
during the embargo, even on public-facing systems with untrusted guest
users and administrators.

HOWEVER, care has to be taken to avoid restricting guests too much, as
them suddenly being unable to establish grants they used to be able to
establish may lead to re-discovery of the issue.

AND: Deployment of the grant table v2 disabling mitigation described
above is NOT permitted during the embargo on public-facing systems with
untrusted guest users and administrators.  This is because such a
configuration change is recognizable by the affected guests.

AND: 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/4UyVfoK9kFAmEmMPYMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZwnkIALnDReUPP6qoQzBWHf9s93UPwM6YVdHl/ao1Nh9l
IyMGtTKjJjtYR9at0tIJDmVecFZzsBtLhQlKWe5DvNP84ZQ99EGDjzsqYKGdJMZK
QIfyUz74UKN5PwEzxeT2C3Q9tOIq2NA41Vax19MjAXSbvAi3jp/0CS

Xen Security Advisory 379 v2 (CVE-2021-28697) - grant table v2 status pages may remain accessible after de-allocation

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28697 / XSA-379
   version 2

 grant table v2 status pages may remain accessible after de-allocation

UPDATES IN VERSION 2


Patches updated to fix a typo in a comment.

Public release.

ISSUE DESCRIPTION
=

Guest get permitted access to certain Xen-owned pages of memory.  The
majority of such pages remain allocated / associated with a guest for
its entire lifetime.  Grant table v2 status pages, however, get
de-allocated when a guest switched (back) from v2 to v1.  The freeing
of such pages requires that the hypervisor know where in the guest
these pages were mapped.  The hypervisor tracks only one use within
guest space, but racing requests from the guest to insert mappings of
these pages may result in any of them to become mapped in multiple
locations.  Upon switching back from v2 to v1, the guest would then
retain access to a page that was freed and perhaps re-used for other
purposes.

IMPACT
==

A malicious guest may be able to elevate its privileges to that of the
host, cause host or guest Denial of Service (DoS), or cause information
leaks.

VULNERABLE SYSTEMS
==

All Xen versions from 4.0 onwards are affected.  Xen versions 3.4 and
older are not affected.

Only x86 HVM and PVH guests permitted to use grant table version 2
interfaces can leverage this vulnerability.  x86 PV guests cannot
leverage this vulnerability.  On Arm, grant table v2 use is explicitly
unsupported.

MITIGATION
==

Running only PV guests will avoid this vulnerability.

Suppressing use of grant table v2 interfaces for HVM or PVH guests will
also avoid this vulnerability.

CREDITS
===

This issue was discovered by Jan Beulich of SUSE.

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.

xsa379.patch   xen-unstable
xsa379-4.15.patch  Xen 4.15.x
xsa379-4.14.patch  Xen 4.14.x - 4.13.x
xsa379-4.12.patch  Xen 4.12.x - 4.11.x

$ sha256sum xsa379*
bdda4cb431301551336388ff7300a6ae95bb75af8fcae09cfb12c22a91d399d9  xsa379.meta
508dbfcac7420ec780df39402116bf7d3f497c4a9d883a369df7bf5340778e6c  xsa379.patch
2a1db918f1fa387a97d7bcb525eaa928fd71a9967e6ced4e7ac6e39a79ab5b80  
xsa379-4.12.patch
c57b72078460f45a5e003db5c4c3669f27310420e04eb16e4413318dfee54fa1  
xsa379-4.14.patch
3154869b12fcde70ce845df723aae4bbb2eb9576d90267c1be01eb6d3c5196e9  
xsa379-4.15.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or PV-guest-only 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.

HOWEVER, deployment of the grant table v2 disabling mitigation described
above is NOT permitted during the embargo on public-facing systems with
untrusted guest users and administrators.  This is because such a
configuration change is recognizable by the affected guests.

AND: 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/4UyVfoK9kFAmEmMPYMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZLogH/icXkFdjXfxIFXLbvcX98qFYFcFbNgyitfngfR4d
VUbiuglViFtSxVY+LytV1RZHEqFiwYCLYcy7lf/EcDyzZT+BLA+S/z5r45F9rQcv
2gwMiQu+xoy1pDTSqVvGb+29NGT/btPRDfRlpaenqjQnGuOX2ymR9zGSmba/PDjp
QVIsSsvEbldlkVzwx9B3C7n+27mUPU6iVnU7j3s60mDfkjz/gIdnuzl8Tv/n6QR0
iZ8URQLn6wobbMBZM1+znfWNeT9dv4UiES1QuUrq1fT7LltQK8mZjAHP+VhXc3XZ
EA9H1LMp5G9Rw+IfgCquQXR5O1usACxnjHM1b9iG2ZP/jZU=
=eASl
-END PGP SIGNATURE-


xsa379.meta
Description: Binary data


xsa379.patch
Description: Binary data


xsa379-4.12.patch
Description: Binary data


xsa379-4.14.patch
Description: Binary data


xsa379-4.15.patch
Description: Binary data

Xen Security Advisory 375 v4 (CVE-2021-0089,CVE-2021-26313) - Speculative Code Store Bypass

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

  Xen Security Advisory CVE-2021-0089,CVE-2021-26313 / XSA-375
version 4

Speculative Code Store Bypass

UPDATES IN VERSION 4


Correct the link to the AMD bulletin.

ISSUE DESCRIPTION
=

Modern superscalar processors may employ sophisticated decoding and
caching of the instruction stream to improve performance.  However, a
consequence is that self-modifying code updates may not take effect
instantly.

Whatever the architectural guarantees, some CPUs have microarchitectural
behaviour whereby the stale instruction stream may be speculatively
decoded and executed.

Speculation of this form can suffer from type confusion in registers,
and potentially leak data.

For more details, see:
  https://www.vusec.net/projects/fpvi-scsb
  https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1003
  
https://software.intel.com/content/www/us/en/develop/articles/software-security-guidance/advisory-guidance/speculative-code-store-bypass.html
  
https://software.intel.com/content/www/us/en/develop/articles/software-security-guidance/advisory-guidance/floating-point-value-injection.html
  
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#scsb
  
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#fvpi

IMPACT
==

In attacker might be able to infer the contents of arbitrary host
memory, including memory assigned to other guests.

VULNERABLE SYSTEMS
==

Systems running all versions of Xen are affected.

Whether a CPU is potentially vulnerable depends on its
microarchitecture.  Consult your hardware vendor.

Xen running on ARM does not have runtime self-modying code, so is
believed to be not vulnerable, irrespective of any hardware
susceptibility.

Xen running on x86 does have runtime self-modying code as part of
emulation, and is believed to be potentially vulnerable.

Xen is not vulnerable if retpoline or lfence mitigations for Spectre v2
protection are active.  Protections depend on compiler support (as
indicated by INDIRECT_THUNK), and a runtime setting (BTI-Thunk):

  # xl dmesg | grep -e INDIRECT_THUNK -e BTI-Thunk
  (XEN)   Compiled-in support: INDIRECT_THUNK SHADOW_PAGING
  (XEN)   Xen settings: BTI-Thunk RETPOLINE, SPEC_CTRL: IBRS+ SSBD-, Other: 
SRB_LOCK+ IBPB L1D_FLUSH VERW BRANCH_HARDEN

BTI-Thunk as either RETPOLINE or LFENCE prevents the vulnerability.

MITIGATION
==

If Spectre v2 support is compiled in, but JMP is used by default,
RETPOLINE or LFENCE can be selected with `spec-ctrl=bti-thunk=retpoline`
or `spec-ctrl=bti-thunk=lfence`.

CREDITS
===

This issue was discovered by Enrico Barberis, Hany Ragab, Herbert Bos,
and Cristiano Giuffrida from the VUSec group at VU Amsterdam.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.  Note that
in 4.13 and newer the patch will only take effect when the
SPECULATIVE_HARDEN_BRANCH hypervisor config option is enabled.  4.12 and
older do not have such an option, and the change will take effect
unconditionally.

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.

xsa375.patch   xen-unstable - 4.14.x
xsa375-4.13.patch  Xen 4.13.x
xsa375-4.12.patch  Xen 4.12.x - 4.11.x

$ sha256sum xsa375*
367d5bb97c942b9f744a57645df87148772c0879de6f351f36f88147f3958e83  xsa375.meta
301ef80da837bc2af36a0958f35f42f4d267b20ec6e91ae5faf2616167ef49f8  xsa375.patch
dc024daf17242b6477a16a349754a94b2b25cbbfd8c14475741b778710a44c93  
xsa375-4.12.patch
f70511d843c6617b932da11ffe857e2e3aa3834ccff07d4d0beba90d63a3dae2  
xsa375-4.13.patch
$

NOTE CONCERNING CVE-2021-0086 / CVE-2021-26314
==

Floating Point Value Injection (FPVI) was discovered and disclosed in
the same research as SCSB.  Xen on x86 does in some cases emulate
floating point operations with guest provided inputs, but does not have
subsequent control flow dependent on results, transient or otherwise, of
the operation.

Therefore, we believe Xen is not vulnerable to FPVI, irrespective of any
hardware susceptibility.

NOTE CONCERNING MULTIPLE CVES
=

Intel and AMD allocated different CVEs for SCSB and FPVI.  We have
included both on this advisory.  The allocations are as follows:

  Issue | Intel | AMD
  --+---+---
  SCSB  | CVE-2021-0089 | CVE-2021-26313
  FPVI  | CVE-2021-0086 | CVE-2021-26314

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted dur

Xen Security Advisory 375 v3 (CVE-2021-0089,CVE-2021-26313) - Speculative Code Store Bypass

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

  Xen Security Advisory CVE-2021-0089,CVE-2021-26313 / XSA-375
  version 3

Speculative Code Store Bypass

UPDATES IN VERSION 3


Added additional CVE, as Intel and AMD allocated different ones.

ISSUE DESCRIPTION
=

Modern superscalar processors may employ sophisticated decoding and
caching of the instruction stream to improve performance.  However, a
consequence is that self-modifying code updates may not take effect
instantly.

Whatever the architectural guarantees, some CPUs have microarchitectural
behaviour whereby the stale instruction stream may be speculatively
decoded and executed.

Speculation of this form can suffer from type confusion in registers,
and potentially leak data.

For more details, see:
  https://www.vusec.net/projects/fpvi-scsb
  https://www.amd.com/en/corporate-product-security-bulletin-amd-sb-1003
  
https://software.intel.com/content/www/us/en/develop/articles/software-security-guidance/advisory-guidance/speculative-code-store-bypass.html
  
https://software.intel.com/content/www/us/en/develop/articles/software-security-guidance/advisory-guidance/floating-point-value-injection.html
  
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#scsb
  
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#fvpi

IMPACT
==

In attacker might be able to infer the contents of arbitrary host
memory, including memory assigned to other guests.

VULNERABLE SYSTEMS
==

Systems running all versions of Xen are affected.

Whether a CPU is potentially vulnerable depends on its
microarchitecture.  Consult your hardware vendor.

Xen running on ARM does not have runtime self-modying code, so is
believed to be not vulnerable, irrespective of any hardware
susceptibility.

Xen running on x86 does have runtime self-modying code as part of
emulation, and is believed to be potentially vulnerable.

Xen is not vulnerable if retpoline or lfence mitigations for Spectre v2
protection are active.  Protections depend on compiler support (as
indicated by INDIRECT_THUNK), and a runtime setting (BTI-Thunk):

  # xl dmesg | grep -e INDIRECT_THUNK -e BTI-Thunk
  (XEN)   Compiled-in support: INDIRECT_THUNK SHADOW_PAGING
  (XEN)   Xen settings: BTI-Thunk RETPOLINE, SPEC_CTRL: IBRS+ SSBD-, Other: 
SRB_LOCK+ IBPB L1D_FLUSH VERW BRANCH_HARDEN

BTI-Thunk as either RETPOLINE or LFENCE prevents the vulnerability.

MITIGATION
==

If Spectre v2 support is compiled in, but JMP is used by default,
RETPOLINE or LFENCE can be selected with `spec-ctrl=bti-thunk=retpoline`
or `spec-ctrl=bti-thunk=lfence`.

CREDITS
===

This issue was discovered by Enrico Barberis, Hany Ragab, Herbert Bos,
and Cristiano Giuffrida from the VUSec group at VU Amsterdam.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.  Note that
in 4.13 and newer the patch will only take effect when the
SPECULATIVE_HARDEN_BRANCH hypervisor config option is enabled.  4.12 and
older do not have such an option, and the change will take effect
unconditionally.

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.

xsa375.patch   xen-unstable - 4.14.x
xsa375-4.13.patch  Xen 4.13.x
xsa375-4.12.patch  Xen 4.12.x - 4.11.x

$ sha256sum xsa375*
367d5bb97c942b9f744a57645df87148772c0879de6f351f36f88147f3958e83  xsa375.meta
301ef80da837bc2af36a0958f35f42f4d267b20ec6e91ae5faf2616167ef49f8  xsa375.patch
dc024daf17242b6477a16a349754a94b2b25cbbfd8c14475741b778710a44c93  
xsa375-4.12.patch
f70511d843c6617b932da11ffe857e2e3aa3834ccff07d4d0beba90d63a3dae2  
xsa375-4.13.patch
$

NOTE CONCERNING CVE-2021-0086 / CVE-2021-26314
==

Floating Point Value Injection (FPVI) was discovered and disclosed in
the same research as SCSB.  Xen on x86 does in some cases emulate
floating point operations with guest provided inputs, but does not have
subsequent control flow dependent on results, transient or otherwise, of
the operation.

Therefore, we believe Xen is not vulnerable to FPVI, irrespective of any
hardware susceptibility.

NOTE CONCERNING MULTIPLE CVES
=

Intel and AMD allocated different CVEs for SCSB and FPVI.  We have
included both on this advisory.  The allocations are as follows:

  Issue | Intel | AMD
  --+---+---
  SCSB  | CVE-2021-0089 | CVE-2021-26313
  FPVI  | CVE-2021-0086 | CVE-2021-26314

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially 

Xen Security Advisory 377 v2 (CVE-2021-28690) - x86: TSX Async Abort protections not restored after S3

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28690 / XSA-377
   version 2

x86: TSX Async Abort protections not restored after S3

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

This issue relates to the TSX Async Abort speculative security vulnerability.
Please see https://xenbits.xen.org/xsa/advisory-305.html for details.

Mitigating TAA by disabling TSX (the default and preferred option) requires
selecting a non-default setting in MSR_TSX_CTRL.  This setting isn't restored
after S3 suspend.

IMPACT
==

After using S3 suspend at least once, CPU0 remains vulnerable to TAA.

This is an information leak.  For full details of the impact, see
XSA-305.

VULNERABLE SYSTEMS
==

See XSA-305 for details of susceptibility to TAA.

Only systems which are susceptible to TAA and have the XSA-305 fix are
vulnerable.  Only systems which support S3 suspend/resume are vulnerable.

The vulnerability is only exposed if S3 suspend/resume is used.

MITIGATION
==

Not using S3 suspend/resume avoids the vulnerability.

CREDITS
===

This issue was discovered by Andrew Cooper of Citrix.

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.

xsa377.patch   xen-unstable - Xen 4.13.x
xsa377-4.12.patch  Xen 4.12.x
xsa377-4.11.patch  Xen 4.11.x

$ sha256sum xsa377*
532cb030f97d72e8e534ad97182cd5e3aa0efeef405e255bb49649b4f0dd9947  xsa377.meta
21a30dbf80f6e78057cc7e785c8fda475d5a8a0b6b9442af3bd8ca31dd69becf  xsa377.patch
3279317d56e7b8d0a2b0152b64b4c577381b8b01fa0a1a21ec6f855bb964278a  
xsa377-4.11.patch
65f61f1cb7bb0e068fd32e40755b9a9aae464d15ccd42c94dae68e495c5a45e0  
xsa377-4.12.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/4UyVfoK9kFAmC/oxIMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZZ0wH/AyYmZO221SvMaSa1kGaV9+tATBWtxKEmUr2I+/Y
jOHJ4Ydw2RarJtZ6reYJ+J0qlTdgI65ceo87VEm1bm+LyvxhlLRmkBfavdTg66aX
VU6uPGqJ9HMUY4rwN7aUgsc/qhquMZQYSWd5A/QknhNHlOtXhX0bnaIqgXoAroi7
PRVs3sawkEizIn1Rqc8nLk+xkOrV3xvu+ollj/VNHgPDKU7SFKZiraBzUW7bErCZ
AjCsgM7SalHDKIMpUqco4hutVJ7ykPE/pbEdC7q93TQ+PWE4/QY3JXcjC7L6KN1/
v9rRTIFTR6fc5EcJfhH2zpWi69OWfE/vjM7k9XhpMoAdUZc=
=fqiA
-END PGP SIGNATURE-


xsa377.meta
Description: Binary data


xsa377.patch
Description: Binary data


xsa377-4.11.patch
Description: Binary data


xsa377-4.12.patch
Description: Binary data

Xen Security Advisory 375 v2 (CVE-2021-0089) - Speculative Code Store Bypass

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-0089 / XSA-375
  version 2

Speculative Code Store Bypass

UPDATES IN VERSION 2


New 4.12 backport (also targeting 4.11), addressing a build issue.

Discuss the need for SPECULATIVE_HARDEN_BRANCH in Resolution.

Provide Arm information links.

Public release.

ISSUE DESCRIPTION
=

Modern superscalar processors may employ sophisticated decoding and
caching of the instruction stream to improve performance.  However, a
consequence is that self-modifying code updates may not take effect
instantly.

Whatever the architectural guarantees, some CPUs have microarchitectural
behaviour whereby the stale instruction stream may be speculatively
decoded and executed.

Speculation of this form can suffer from type confusion in registers,
and potentially leak data.

For more details, see:
  https://www.vusec.net/projects/fpvi-scsb
  https://www.amd.com/en/corporate-product-security-bulletin-amd-sb-1003
  
https://software.intel.com/content/www/us/en/develop/articles/software-security-guidance/advisory-guidance/speculative-code-store-bypass.html
  
https://software.intel.com/content/www/us/en/develop/articles/software-security-guidance/advisory-guidance/floating-point-value-injection.html
  
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#scsb
  
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#fvpi

IMPACT
==

In attacker might be able to infer the contents of arbitrary host
memory, including memory assigned to other guests.

VULNERABLE SYSTEMS
==

Systems running all versions of Xen are affected.

Whether a CPU is potentially vulnerable depends on its
microarchitecture.  Consult your hardware vendor.

Xen running on ARM does not have runtime self-modying code, so is
believed to be not vulnerable, irrespective of any hardware
susceptibility.

Xen running on x86 does have runtime self-modying code as part of
emulation, and is believed to be potentially vulnerable.

Xen is not vulnerable if retpoline or lfence mitigations for Spectre v2
protection are active.  Protections depend on compiler support (as
indicated by INDIRECT_THUNK), and a runtime setting (BTI-Thunk):

  # xl dmesg | grep -e INDIRECT_THUNK -e BTI-Thunk
  (XEN)   Compiled-in support: INDIRECT_THUNK SHADOW_PAGING
  (XEN)   Xen settings: BTI-Thunk RETPOLINE, SPEC_CTRL: IBRS+ SSBD-, Other: 
SRB_LOCK+ IBPB L1D_FLUSH VERW BRANCH_HARDEN

BTI-Thunk as either RETPOLINE or LFENCE prevents the vulnerability.

MITIGATION
==

If Spectre v2 support is compiled in, but JMP is used by default,
RETPOLINE or LFENCE can be selected with `spec-ctrl=bti-thunk=retpoline`
or `spec-ctrl=bti-thunk=lfence`.

CREDITS
===

This issue was discovered by Enrico Barberis, Hany Ragab, Herbert Bos,
and Cristiano Giuffrida from the VUSec group at VU Amsterdam.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.  Note that
in 4.13 and newer the patch will only take effect when the
SPECULATIVE_HARDEN_BRANCH hypervisor config option is enabled.  4.12 and
older do not have such an option, and the change will take effect
unconditionally.

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.

xsa375.patch   xen-unstable - 4.14.x
xsa375-4.13.patch  Xen 4.13.x
xsa375-4.12.patch  Xen 4.12.x - 4.11.x

$ sha256sum xsa375*
367d5bb97c942b9f744a57645df87148772c0879de6f351f36f88147f3958e83  xsa375.meta
301ef80da837bc2af36a0958f35f42f4d267b20ec6e91ae5faf2616167ef49f8  xsa375.patch
dc024daf17242b6477a16a349754a94b2b25cbbfd8c14475741b778710a44c93  
xsa375-4.12.patch
f70511d843c6617b932da11ffe857e2e3aa3834ccff07d4d0beba90d63a3dae2  
xsa375-4.13.patch
$

NOTE CONCERNING CVE-2021-0086
=

Floating Point Value Injection (FPVI) was discovered and disclosed in
the same research as SCSB.  Xen on x86 does in some cases emulate
floating point operations with guest provided inputs, but does not have
subsequent control flow dependent on results, transient or otherwise, of
the operation.

Therefore, we believe Xen is not vulnerable to FPVI, irrespective of any
hardware susceptibility.

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 signi

Xen Security Advisory 374 v2 (CVE-2021-28691) - Guest triggered use-after-free in Linux xen-netback

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28691 / XSA-374
   version 2

  Guest triggered use-after-free in Linux xen-netback

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

A malicious or buggy network PV frontend can force Linux netback to
disable the interface and terminate the receive kernel thread
associated with queue 0 in response to the frontend sending a
malformed packet.

Such kernel thread termination will lead to a use-after-free in Linux
netback when the backend is destroyed, as the kernel thread associated
with queue 0 will have already exited and thus the call to
kthread_stop will be performed against a stale pointer.

IMPACT
==

A malicious or buggy frontend driver can trigger a dom0 crash.
Privilege escalation and information leaks cannot be ruled out.

VULNERABLE SYSTEMS
==

Systems using Linux version 5.5 or newer are vulnerable.

MITIGATION
==

On x86 running only HVM guests with emulated network cards will avoid the
issue.  There's however no option in the upstream toolstack to offer only
emulated network cards to guests.

CREDITS
===

This issue was discovered by Michael Brown of iPXE and diagnosed by
Olivier Benjamin, Michael Kurth and Martin Mazein of AWS.

RESOLUTION
==

Applying the attached patch resolves this issue.

xsa374-linux.patch Linux 5.5.0 - 5.12.2

$ sha256sum xsa374*
156cee65022359a5901cce97714d2abb16fef786246b1c4bf509083d21e085d6  
xsa374-linux.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).

Deployment of the mitigation to disable PV network interfaces is NOT
permitted (except where all the affected systems and VMs are
administered and used only by organisations which are members of the
Xen Project Security Issues Predisclosure List).  Specifically,
deployment on public cloud systems is NOT permitted.

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/4UyVfoK9kFAmC/oxIMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZigoIAKNYimzTYl6VQYaqgwMdNzqXCF/PdlQF/tf8PSwm
5VP0ZPbLq6Zn4HOgMBtBzs/GCFtrIWsQGnZji611dkaAh21N1YErXW5jFYMnf1DI
rruCXE1GuL5B4sFvWw7CnMXax6vYe0q5KPoGmyZRV77aT5T+gNMONlGl6raw7/Ne
UAtAv4JDSR5Nc53X0HNK7tNU9tdr4VaLqEKWs+C0W+azOFNGvrTeNDVjBiLqDZbA
st62i3PIFTXu+XzbjZNdM/RMpVVxFSkfdWn53RDVJ2JaFBMxrcVs75aVo3Nfr34Z
Iho+eTPDywP9+4zl/FoModMYHg4rTMHf+jmbi3M/aCOal2U=
=1Dhy
-END PGP SIGNATURE-


xsa374-linux.patch
Description: Binary data

Xen Security Advisory 372 v3 (CVE-2021-28693) - xen/arm: Boot modules are not scrubbed

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28693 / XSA-372
   version 3

xen/arm: Boot modules are not scrubbed

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

The bootloader will load boot modules (e.g. kernel, initramfs...) in a
temporary area before they are copied by Xen to each domain memory.
To ensure sensitive data is not leaked from the modules, Xen must
"scrub" them before handing the page over to the allocator.

Unfortunately, it was discovered that modules will not be scrubbed on
Arm.

IMPACT
==

Sensitive information from the boot modules might be visible to another
domain after boot.

VULNERABLE SYSTEMS
==

Only Arm systems are vulnerable.  System running with "bootscrub=off"
(disabling boot scrubbing) are not vulnerable.

All versions of Xen since 4.12 are vulnerable.

MITIGATION
==

There is no mitigation available.

CREDITS
===

This issue was discovered by Julien Grall of Amazon.

RESOLUTION
==

Applying the appropriate set of attached patches 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.

xsa372/*.patch xen-unstable
xsa372-4.15/*.patchXen 4.15.x
xsa372-4.14/*.patchXen 4.14.x - Xen 4.13.x
xsa372-4.12/*.patchXen 4.12.x

$ sha256sum xsa372* xsa372*/*
06e43684c2d8a3085d55b8b40f57e1b9f1ee47519fac844dcbc21b57fb039915  xsa372.meta
8f872c7abe6c795dbef2e401f2223fda0dbb9d7c57dfebd8047eef37e1caf952  
xsa372-4.12/0001-xen-arm-Create-dom0less-domUs-earlier.patch
a43c6c11481cc3f13900908cee79cc6c5401921f6f4e8858c0796cf301cfe923  
xsa372-4.12/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch
6d1fad53795ebd251520022b6be901215426ba78ccbbc075841698973b74d2a2  
xsa372-4.14/0001-xen-arm-Create-dom0less-domUs-earlier.patch
2ceb5d4d8d4f8a18046721daa3bb29633a620c4794b54e1265f5d4d69a314c3b  
xsa372-4.14/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch
7feae5f9f7f2df0ec38c0b9358dc32671a9955f966b3120e17bb3fd820ce33ff  
xsa372-4.15/0001-xen-arm-Create-dom0less-domUs-earlier.patch
0cc73b4751fa49f68c6584b1c7882606c6e1f18561d8a6547017ab068de4eb4b  
xsa372-4.15/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch
950672405c695ebf6ae59eebeb454bc0738b7afc3efa35ef9680d76eef4d4ec0  
xsa372/0001-xen-arm-Create-dom0less-domUs-earlier.patch
9ceccd39c795e7756052a2f00256e043c8dda42e2c691df30e3f8b59190d6e8e  
xsa372/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.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/4UyVfoK9kFAmC/oxIMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZmdYIAMlZ2woM1hnb97BytpKkRM3v8AnyP4xhm29OoVI+
eaclrapZBPxi8qxv0+fxhe/2/t9gf98miEJftI8VRz5btiStmsgIjlEXUGpC6iwE
u7HmLzu7QBX7r2FzpSTFnVVdbFwXCU3scYuO4qM8frCpxH4kevSSxPrT5E/oFVvA
Y83ux8aKg041WTVQvK0gEVA7CgRVoxmbiYeag2JIaRGt8WnEKprbmGWQ5+DYq+pr
8tsLppHtyxppqSa7d6L67xdiNoRqAacfIezNFTpSIdyfS1m0QIIAJTr6Bg7Fd6zi
F2AYcoZiNO53OSnobH3c64axIc5iBINZeXisVMnTDzKU3XE=
=eQ/r
-END PGP SIGNATURE-


xsa372.meta
Description: Binary data


xsa372-4.12/0001-xen-arm-Create-dom0less-domUs-earlier.patch
Description: Binary data


xsa372-4.12/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch
Description: Binary data


xsa372-4.14/0001-xen-arm-Create-dom0less-domUs-earlier.patch
Description: Binary data


xsa372-4.14/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch
Description: Binary data


xsa372-4.15/0001-xen-arm-Create-dom0less-domUs-earlier.patch
Description: Binary data


xsa372-4.15/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch
Description: Binary data


xsa372/0001-xen-arm-Create-dom0less-domUs-earlier.patch
Description: Binary data


xsa372/0002-xen-arm-Boot-modules-should-always-be-scrubbed

Xen Security Advisory 370 v2 (CVE-2021-28689) - x86: Speculative vulnerabilities with bare (non-shim) 32-bit PV guests

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28689 / XSA-370
   version 2

   x86: Speculative vulnerabilities with bare (non-shim) 32-bit PV guests

UPDATES IN VERSION 2


Note that the patch is docs-only and the affected version ranges, in the
files summary of the Resolution section.

Public release.

ISSUE DESCRIPTION
=

32-bit x86 PV guest kernels run in ring 1.  At the time when Xen was
developed, this area of the i386 architecture was rarely used, which is why
Xen was able to use it to implement paravirtualisation, Xen's novel
approach to virtualization.  In AMD64, Xen had to use a different
implementation approach, so Xen does not use ring 1 to support 64-bit
guests.  With the focus now being on 64-bit systems, and the availability
of explicit hardware support for virtualization, fixing speculation issues
in ring 1 is not a priority for processor companies.

Indirect Branch Restricted Speculation (IBRS) is an architectural x86
extension put together to combat speculative execution sidechannel attacks,
including Spectre v2.  It was retrofitted in microcode to existing CPUs.

For more details on Spectre v2, see:
  http://xenbits.xen.org/xsa/advisory-254.html

However, IBRS does not architecturally protect ring 0 from predictions
learnt in ring 1.

For more details, see:
  
https://software.intel.com/security-software-guidance/deep-dives/deep-dive-indirect-branch-restricted-speculation

Similar situations may exist with other mitigations for other kinds of
speculative execution attacks.  The situation is quite likely to be similar
for speculative execution attacks which have yet to be discovered,
disclosed, or mitigated.

IMPACT
==

A malicious 32-bit guest kernel may be able to mount a Spectre v2 attack
against Xen, despite the presence hardware protections being active.

It therefore might be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.

VULNERABLE SYSTEMS
==

Systems running all versions of Xen are affected.

Only x86 systems are vulnerable, and only CPUs which are potentially
vulnerable to Spectre v2.  Consult your hardware manufacturer.

The vulnerability can only be exploited by 32-bit PV guests which are not
run in PV-Shim.

MITIGATION
==

Running 32-bit PV guests under PV-Shim avoids the vulnerability when Spectre v2
protections are otherwise enabled on the system.

PV shim is available and fully security-supported in all
security-supported versions of Xen.  Using shim is the recommended
configuration.

Not running 32-bit PV guests avoids the vulnerability.

CREDITS
===

This issue was discovered by Jann Horn of Google Project Zero.

RESOLUTION
==

There is no resolution available, and none is ever expected.

The patches provided only update the security support statement.

The first patch is an unavoidable consequence of the discussions
above; the support status described is in effect immediately.

The security team does not consider the support status listed in patch
1 to be particularly useful; however, we do not feel we have the
authority to completely de-support non-shim 32-bit PV guests without
community consultation.

The second patch is the long-term support status the security team
proposes to the community. It will not become effective until three
weeks after the XSA-370 embargo lifts, and only if there are no
objections raised before that point.

If you need security support for un-shimmed 32-bit PV guests, please
make your voice heard on xen-devel@lists.xenproject.org (or to
secur...@xenproject.org) as soon as possible after the embargo lifts.

xsa370/*.patch Xen unstable (docs only)
 Xen (all versions)

$ sha256sum xsa370* xsa370*/*
ffb6e1be6a849b8e6930386d70817f53970f3d71a0a89980565c87070e85a7e2  xsa370.meta
45c11df550f1900663a388106d6625e84fa280881e613825c830b1984f87b3a9  
xsa370/0001-SUPPORT.md-Document-speculative-attacks-status-of-no.patch
48dfe434bcdf4f08b623b639079fd1c9f9b1939b279200550dbae7736340cb53  
xsa370/0002-SUPPORT.md-Un-shimmed-32-bit-PV-guests-are-no-longer.patch
$

BARE 32 BIT PV SECURITY SUPPORT STATUS
==

This advisory discloses only a (very serious) information disclosure
vulnerability exploitable by bare 32 bit PV guests, using speculative
execution.

We are considering further entirely withdrawing security support for
configurations with non-shim 32 bit PV guests.  Any such decision,
including the precise scope of the (de)support, will be made following
public community discussion.

The result of that public process will be a patch to the security support
statement, backported (as applicable) to the relevant trees.

NOTE REGARDING EMBARGO
==

In principle, the fact that the new CPU facilities are not capable of
protecting ring 0 Xen from a ring 1 PV guest, might be gleaned from
the hardware ven

Xen Security Advisory 371 v3 (CVE-2021-28688) - Linux: blkback driver may leak persistent grants

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28688 / XSA-371
   version 3

   Linux: blkback driver may leak persistent grants

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

The fix for XSA-365 includes initialization of pointers such that
subsequent cleanup code wouldn't use uninitialized or stale values.
This initialization went too far and may under certain conditions also
overwrite pointers which are in need of cleaning up.  The lack of
cleanup would result in leaking persistent grants.  The leak in turn
would prevent fully cleaning up after a respective guest has died,
leaving around zombie domains.

IMPACT
==

A malicious or buggy frontend driver may be able to cause resource leaks
from the corresponding backend driver.  This can result in a host-wide
Denial of Sevice (DoS).

VULNERABLE SYSTEMS
==

All Linux versions having the fix for XSA-365 applied are vulnerable.
XSA-365 was classified to affect versions back to at least 3.11.

MITIGATION
==

Reconfiguring guests to use alternative (e.g. qemu-based) backends may
avoid the vulnerability.

Avoiding the use of persistent grants will also avoid the vulnerability.
This can be achieved by passing the "feature_persistent=0" module option
to the xen-blkback driver.

CREDITS
===

This issue was discovered by Nicolai Stange of SUSE.

RESOLUTION
==

Applying the attached patch resolves this issue.

xsa371-linux.patch   Linux 5.12-rc, 5.11.1 onwards, 5.10.18 onwards
  Linux 5.10.0 - 5.10.17, 5.11.0
  Linux 4.4 - 5.9
   Linux 3.11 - 4.3

$ sha256sum xsa371*
1b2472253aa82385b3eff280fa4adf52742f06813fc093f5f86cd4a3021f736c  
xsa371-linux.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.

HOWEVER, deployment of the mitigations described above is NOT permitted
during the embargo on public-facing systems with untrusted guest users
and administrators.  This is because such configuration changes may be
recognizable by the affected guests.

AND: 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/4UyVfoK9kFAmBjBWYMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZbkQIAKjv5DaESSOUA8DzOk4LmBZQHIMtTsN2wF2Q0/6g
3hJ3HoGzQwul00eUem+sbAqrEKJAEGLrcWpAGlcp8jW5i+44dyHE4o4vDmUOLx/x
eJGMKwhv2Xe7Us15Fh4ioOBtmO6/AH60Scbid3aZ6zlJiUEPwpotzD9Jm/nR+B/E
/KRsXZ+dTIZpeke9vVXbml/nrq/xwvpAZrEGeXBg1FDUHNsGWEeqPFq2ZfygVw22
x5loXeb8cqIETuA3EJQ1fx0Ioqnh3Q85TtNTCTpZrKcrTqJX+lZTlrEn4iAaMvp1
Bp/Mu9dkFrIJaid0iwdJKk2STsROh5ZCXCOyFOo5LFvFoKE=
=DlVS
-END PGP SIGNATURE-


xsa371-linux.patch
Description: Binary data

Xen Security Advisory 368 v3 (CVE-2021-28687) - HVM soft-reset crashes toolstack

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28687 / XSA-368
  version 3

   HVM soft-reset crashes toolstack

UPDATES IN VERSION 3


CVE assigned.

ISSUE DESCRIPTION
=

libxl requires all data structures passed across its public interface
to be initialized before use and disposed of afterwards by calling a
specific set of functions.  Many internal data structures also require
this initialize / dispose discipline, but not all of them.

When the "soft reset" feature was implemented, the
libxl__domain_suspend_state structure didn't require any
initialization or disposal.  At some point later, an initialization
function was introduced for the structure; but the "soft reset" path
wasn't refactored to call the initialization function.  When a guest
nwo initiates a "soft reboot", uninitialized data structure leads to
an assert() when later code finds the structure in an unexpected
state.

The effect of this is to crash the process monitoring the guest.  How
this affects the system depends on the structure of the toolstack.

For xl, this will have no security-relevant effect: every VM has its
own independent monitoring process, which contains no state.  The
domain in question will hang in a crashed state, but can be destroyed
by `xl destroy` just like any other non-cooperating domain.

For daemon-based toolstacks linked against libxl, such as libvirt,
this will crash the toolstack, losing the state of any in-progress
operations (localized DoS), and preventing further administrator
operations unless the daemon is configured to restart automatically
(system-wide DoS).  If crashes "leak" resources, then repeated crashes
could use up resources, also causing a system-wide DoS.

IMPACT
==

A malicious guest can crash the management daemon, leading to at least
a localized, possibly system-wide denial-of-service.

VULNERABLE SYSTEMS
==

Only Xen versions 4.12 through 4.14 are affected.  Earlier versions
are not affected.

The issue affects only systems with a guest monitoring process, which
is linked against libxl, and which is important other than simply for
the functioning of one particular guest.  libvirt is one common
toolstack affected.  Systems using the `xl` command-line tool should
generally suffer no security-relevant effects.

The xapi toolstack does not currently link against libxl, and so is
not affected.

MITIGATION
==

Ensuring that any management daemons are restarted automatically after
a crash will partially mitigate the issue.

CREDITS
===

This issue was discovered by Olaf Hering.

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.

xsa368.patch   xen-unstable
xsa368-4.14.patch  Xen 4.14.x
xsa368-4.13.patch  Xen 4.13.x - Xen 4.12.x

$ sha256sum xsa368*
e80f33c3ce45372fef7bd91ec71b2b66e557176b79f9771872ce111bfff34150  xsa368.meta
b82f2b110514cdf47a2688913ad5af68b01050751d56705a15ddf9a970b6fa0d  xsa368.patch
636df70ae5eaf00b50ef0b5ac219a2aeda771c66833fae88e7ee43b18ae889f4  
xsa368-4.13.patch
55bbe59c75b69f493e364dfcf6cdbc7db4acd32dbf0b4d2466815b7c1f1823ce  
xsa368-4.14.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/4UyVfoK9kFAmBTXAAMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZdgcH/RTW41tLPh8KHJ+82qefaI2EUBK3nmNnR5hnye3c
9GPP/QB7QdHp+JSIRTAZxOayBQeFEcYSX/5VxDypIiqT02wHS9hDr3jcpOfGLcdt
MiN9kB3vYqe353Lask0mN7AX3J5v3wvrYzBRx9ccaYcX/Jcubrx6Jy5laQSYpTUu
4GCeLZQ2tHI8N3ZHiKI7YUyxmn9vKgvFil1gyuk8L5x6npnW4ixdWF0MRyHe7wbS
dbZbug0g6bbJbs4CFZbm1CbQjGGOwznfT8z9ppmgPdi+33X+Cimz3wlbpXeJKpZk
/nJObobdPGk7ClChvUjntv0oaZ+2zFoUoe3Yc08aa+B29e8=
=Dehk
-END PGP SIGNATURE-


xsa368.meta
Description: B

Xen Security Advisory 368 v2 - HVM soft-reset crashes toolstack

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-368
  version 2

   HVM soft-reset crashes toolstack

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

libxl requires all data structures passed across its public interface
to be initialized before use and disposed of afterwards by calling a
specific set of functions.  Many internal data structures also require
this initialize / dispose discipline, but not all of them.

When the "soft reset" feature was implemented, the
libxl__domain_suspend_state structure didn't require any
initialization or disposal.  At some point later, an initialization
function was introduced for the structure; but the "soft reset" path
wasn't refactored to call the initialization function.  When a guest
nwo initiates a "soft reboot", uninitialized data structure leads to
an assert() when later code finds the structure in an unexpected
state.

The effect of this is to crash the process monitoring the guest.  How
this affects the system depends on the structure of the toolstack.

For xl, this will have no security-relevant effect: every VM has its
own independent monitoring process, which contains no state.  The
domain in question will hang in a crashed state, but can be destroyed
by `xl destroy` just like any other non-cooperating domain.

For daemon-based toolstacks linked against libxl, such as libvirt,
this will crash the toolstack, losing the state of any in-progress
operations (localized DoS), and preventing further administrator
operations unless the daemon is configured to restart automatically
(system-wide DoS).  If crashes "leak" resources, then repeated crashes
could use up resources, also causing a system-wide DoS.

IMPACT
==

A malicious guest can crash the management daemon, leading to at least
a localized, possibly system-wide denial-of-service.

VULNERABLE SYSTEMS
==

Only Xen versions 4.12 through 4.14 are affected.  Earlier versions
are not affected.

The issue affects only systems with a guest monitoring process, which
is linked against libxl, and which is important other than simply for
the functioning of one particular guest.  libvirt is one common
toolstack affected.  Systems using the `xl` command-line tool should
generally suffer no security-relevant effects.

The xapi toolstack does not currently link against libxl, and so is
not affected.

MITIGATION
==

Ensuring that any management daemons are restarted automatically after
a crash will partially mitigate the issue.

CREDITS
===

This issue was discovered by Olaf Hering.

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.

xsa368.patch   xen-unstable
xsa368-4.14.patch  Xen 4.14.x
xsa368-4.13.patch  Xen 4.13.x - Xen 4.12.x

$ sha256sum xsa368*
e80f33c3ce45372fef7bd91ec71b2b66e557176b79f9771872ce111bfff34150  xsa368.meta
b82f2b110514cdf47a2688913ad5af68b01050751d56705a15ddf9a970b6fa0d  xsa368.patch
636df70ae5eaf00b50ef0b5ac219a2aeda771c66833fae88e7ee43b18ae889f4  
xsa368-4.13.patch
55bbe59c75b69f493e364dfcf6cdbc7db4acd32dbf0b4d2466815b7c1f1823ce  
xsa368-4.14.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/4UyVfoK9kFAmBTQEMMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZDAIH/ibVSFJRukaH4TKAtm0Qy7Qb0jSF6u5lHdUH4lfa
EXTAS4/vAJI70bMt2yePGoaa+QPSJ340MwlKcW8GerAEWeW0hTxOp23GGavEwbtu
I+OFdls2YGrxGM2FMQR0ZEftV4jsyVAcCNF6oq6nqzTDe1OZC0bQSDUL69CWnIKn
hC9Br/hV3AuijwwQdOGQoe+rj8aZK134UaNjr0AI9e1l2jEsJ3NxC3IxeHy4/J3E
meoHKtTRZXFdG2VMu709jqrnhpOQcZDT+meiNhoOdUvXyPBa2MzVj3XY32yWuJxa
Fi7qrpXIAZ8qNbCbLIbNYMGlgB+7sLsKQULycgai8Sk7QpU=
=ea+C
-END PGP SIGNATURE-


xsa368.meta
Description: Binary d

Xen Security Advisory 369 v2 (CVE-2021-28039) - Linux: special config may crash when trying to map foreign pages

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28039 / XSA-369
  version 2

   Linux: special config may crash when trying to map foreign pages

UPDATES IN VERSION 2


CVE assigned.

ISSUE DESCRIPTION
=

With CONFIG_XEN_BALLOON_MEMORY_HOTPLUG disabled and
CONFIG_XEN_UNPOPULATED_ALLOC enabled the Linux kernel will use guest
physical addresses allocated via the ZONE_DEVICE functionality for
mapping foreign guest's pages.

This will result in problems, as the p2m list will only cover the initial
memory size of the domain plus some padding at the end. Most ZONE_DEVICE
allocated addresses will be outside the p2m range and thus a mapping can't
be established with those memory addresses, resulting in a crash.

The attack involves doing I/O requiring large amounts of data to be
mapped by the Dom0 or driver domain.  The amount of data needed to
result in a crash can vary depending on the memory layout of the
affected Dom0 or driver domain.

IMPACT
==

A Dom0 or driver domain based on a Linux kernel (configured as
described above) can be crashed by a malicious guest administrator, or
possibly malicious unprivileged guest processes.

VULNERABLE SYSTEMS
==

Only x86 paravirtualized (PV) Dom0 or driver domains are
affected.

Only Linux kernels configured *with* CONFIG_XEN_UNPOPULATED_ALLOC and
*without* CONFIG_XEN_BALLOON_MEMORY_HOTPLUG are vulnerable.  Only
kernels from kernel version 5.9 onwards are affected.

CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is enabled by default in upstream
Linux when Xen support is enabled, so kernels using upstream default
Kconfig are not affected.  Most distribution kernels supporting Xen
dom0 use are likewise not vulnerable.

Arm systems or x86 PVH or x86 HVM driver domains are not affected.

MITIGATION
==

There is no mitigation available.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa369-linux.patch   Linux 5.9-stable - 5.12-rc

$ sha256sum xsa369*
937df4f078a070cf47bdd718c6b8a042ec6bee255eedc422d833c2ae3dd561c7  
xsa369-linux.patch
$

CREDITS
===

This issue was discovered by Marek Marczykowski-Górecki of Invisible
Things Lab.

For patch:
Reported-by: Marek Marczykowski-Górecki 

NOTE REGARDING LACK OF EMBARGO
==

This was reported publicly multiple times, before the XSA could be
issued.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmBCZVUMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZp8wIALvuzrh0iQDIg86Mx/eTtfVflmrz91YiDPfhrDj1
L1D2lR+uFPKFpb3CdDTlzKoby/1ym4wbTLCjnDdXxjmPTdn4KybcBNbNONt2p69X
dr/3KsO6yW5tjSi3FRZnnyTnTJN/q65tijG23sAcF7KuNW+xT2d70tWMH+LeMQZO
fGkztK08cZspFfZZiOJHuqi5qpzoaBw7/vqlCphoiDMeE1EOGpaa/+bGb4doehyj
dN8dyEWbyWdTp5lAxmduJfDMuixeESIxPnXP8jV3Z9b+Gt5l9S0cM+DCWDRUkW3M
W0Z7va35sFLCx4+N7fLuzMUkzoLWpTJq2i2m9lploexe3nY=
=PtNk
-END PGP SIGNATURE-


xsa369-linux.patch
Description: Binary data

Xen Security Advisory 367 v2 (CVE-2021-28038) - Linux: netback fails to honor grant mapping errors

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2021-28038 / XSA-367
  version 2

  Linux: netback fails to honor grant mapping errors

UPDATES IN VERSION 2


CVE assigned.

ISSUE DESCRIPTION
=

XSA-362 tried to address issues here, but in the case of the netback
driver the changes were insufficient: It left the relevant function
invocation with, effectively, no error handling at all.  As a result,
memory allocation failures there could still lead to frontend-induced
crashes of the backend.

IMPACT
==

A malicious or buggy networking frontend driver may be able to crash
the corresponding backend driver, potentially affecting the entire
domain running the backend driver.  In a typical (non-disaggregated)
system that is a host-wide denial of service (DoS).

VULNERABLE SYSTEMS
==

Linux versions from at least 2.6.39 onwards are vulnerable, when run in
PV mode.  Earlier versions differ significantly in behavior and may
therefore instead surface other issues under the same conditions.  Linux
run in HVM / PVH modes is not vulnerable.

MITIGATION
==

For Linux, running the backends in HVM or PVH domains will avoid the
vulnerability.  For example, by running the dom0 in PVH mode.

In all other cases there is no known mitigation.

RESOLUTION
==

Applying the attached patch resolves this issue.

xsa367-linux.patch   Linux 5.12-rc

$ sha256sum xsa367*
b0244bfddee91cd7986172893e70664b74e698c5d44f25865870f179f80f9a92  
xsa367-linux.patch
$

CREDITS
===

This issue was reported by Intel's kernel test robot and recognized as a
security issue by Jan Beulich of SUSE.

NOTE REGARDING LACK OF EMBARGO
==

This issue was reported publicly, before the XSA could be issued.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmBCZVEMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZfqAH/i7ypTUP90UIxeyMB9XmNRiqD+LaTSBExt8xTowd
zbsWrxFYnZRPSLqs/dVHlDQfF65eD40Agh/Hxp5f0hGHjv8x1kepvpo2di1ovA2h
C8/WpOK2nFq77/GTG2mAsJA3ltDF0WJsr5oqaBNVf/lwQSmiescTWtI6+LDFmmpd
q1EyKPUClKZW3PoZkCVmiWDtqhVJc3LaJJcy4x/Zd4EgV+uGi2wsYsiQzObrwPss
2D5laUr8RJcSTE7+bXlMA8KnzrOZ6UqK1YIPSGIYBOJnhizGf9CBZCxcNTONWQFC
zh1d9GAv93fugE37xRHE7PRjgl/RVO5rn0k5EQw5GTa676A=
=GKdV
-END PGP SIGNATURE-


xsa367-linux.patch
Description: Binary data

Xen Security Advisory 369 v1 - Linux: special config may crash when trying to map foreign pages

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-369

   Linux: special config may crash when trying to map foreign pages

ISSUE DESCRIPTION
=

With CONFIG_XEN_BALLOON_MEMORY_HOTPLUG disabled and
CONFIG_XEN_UNPOPULATED_ALLOC enabled the Linux kernel will use guest
physical addresses allocated via the ZONE_DEVICE functionality for
mapping foreign guest's pages.

This will result in problems, as the p2m list will only cover the initial
memory size of the domain plus some padding at the end. Most ZONE_DEVICE
allocated addresses will be outside the p2m range and thus a mapping can't
be established with those memory addresses, resulting in a crash.

The attack involves doing I/O requiring large amounts of data to be
mapped by the Dom0 or driver domain.  The amount of data needed to
result in a crash can vary depending on the memory layout of the
affected Dom0 or driver domain.

IMPACT
==

A Dom0 or driver domain based on a Linux kernel (configured as
described above) can be crashed by a malicious guest administrator, or
possibly malicious unprivileged guest processes.

VULNERABLE SYSTEMS
==

Only x86 paravirtualized (PV) Dom0 or driver domains are
affected.

Only Linux kernels configured *with* CONFIG_XEN_UNPOPULATED_ALLOC and
*without* CONFIG_XEN_BALLOON_MEMORY_HOTPLUG are vulnerable.  Only
kernels from kernel version 5.9 onwards are affected.

CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is enabled by default in upstream
Linux when Xen support is enabled, so kernels using upstream default
Kconfig are not affected.  Most distribution kernels supporting Xen
dom0 use are likewise not vulnerable.

Arm systems or x86 PVH or x86 HVM driver domains are not affected.

MITIGATION
==

There is no mitigation available.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa369-linux.patch   Linux 5.9-stable - 5.12-rc

$ sha256sum xsa369*
937df4f078a070cf47bdd718c6b8a042ec6bee255eedc422d833c2ae3dd561c7  
xsa369-linux.patch
$

CREDITS
===

This issue was discovered by Marek Marczykowski-Górecki of Invisible
Things Lab.

For patch:
Reported-by: Marek Marczykowski-Górecki 

NOTE REGARDING LACK OF EMBARGO
==

This was reported publicly multiple times, before the XSA could be
issued.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmBAvMQMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ5PoH/2EY28X1Fe+2RW5SrnAo2dZWLXeIrXQIXbsDCdlI
GKhFChUhYHJP3wLhE4F7J5SAjl48ta/gtdpbpJWXsZSS+2KIdV/dDZ3ZA6cxWFAI
DuVvqqt5O0xpF02bgTZrL1GUL8975L0O7cwtGmsIbPjVSF5UktuLS0Q1zRAiYvG9
l5Xu32nekxz2fGebMYrJTIPYNc8LOg3d+MIAE4W1u3Wj46S8yRJhyNQmsPQXZTEk
nlTp0ed8ScAt7pIZn7dbnLz8zUAQ64h2yar0UBih51kd3Bss5E4PXsS0zlXlVNfk
046nBhbFfB3dgM49NlJ3oHhiZh6dN5LpMblmGK4Tb+FJqNE=
=QwG+
-END PGP SIGNATURE-


xsa369-linux.patch
Description: Binary data

Xen Security Advisory 367 v1 - Linux: netback fails to honor grant mapping errors

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-367

  Linux: netback fails to honor grant mapping errors

ISSUE DESCRIPTION
=

XSA-362 tried to address issues here, but in the case of the netback
driver the changes were insufficient: It left the relevant function
invocation with, effectively, no error handling at all.  As a result,
memory allocation failures there could still lead to frontend-induced
crashes of the backend.

IMPACT
==

A malicious or buggy networking frontend driver may be able to crash
the corresponding backend driver, potentially affecting the entire
domain running the backend driver.  In a typical (non-disaggregated)
system that is a host-wide denial of service (DoS).

VULNERABLE SYSTEMS
==

Linux versions from at least 2.6.39 onwards are vulnerable, when run in
PV mode.  Earlier versions differ significantly in behavior and may
therefore instead surface other issues under the same conditions.  Linux
run in HVM / PVH modes is not vulnerable.

MITIGATION
==

For Linux, running the backends in HVM or PVH domains will avoid the
vulnerability.  For example, by running the dom0 in PVH mode.

In all other cases there is no known mitigation.

RESOLUTION
==

Applying the attached patch resolves this issue.

xsa367-linux.patch   Linux 5.12-rc

$ sha256sum xsa367*
b0244bfddee91cd7986172893e70664b74e698c5d44f25865870f179f80f9a92  
xsa367-linux.patch
$

CREDITS
===

This issue was reported by Intel's kernel test robot and recognized as a
security issue by Jan Beulich of SUSE.

NOTE REGARDING LACK OF EMBARGO
==

This issue was reported publicly, before the XSA could be issued.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmBAuOYMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZUCAH/1zw5d2l1R3k+nvJ659plwOYDe8Cmh4GeJ02PoUv
fC/5efe7l/tXEmfg4rg5WiY8JZqQGeGmhwiOs8bI/8c5IXucaPOM1wDUaHUMkWTA
tl/P/tbDamzd1/dSK4DdILTApibU+M/nmUn0sBBYpu53VUbeyXq2EAtjmliKgCG9
Oo4PW4ys5ro+hwrPtYdLD1ktIN64+C+TqkKUdJset7po5sWX4nV1Cwp/4oKaNyeF
Alh495TUCnhgc8gnXUgXhmxWKp3Iag/tHjmtu34mT5HHZdBrNBShFKhHSP5bJHE2
CxYD1b/KbkRiLPOgZXNec+ikDQT4bTCeVLpnWvOXQ1FTXR4=
=hY2s
-END PGP SIGNATURE-


xsa367-linux.patch
Description: Binary data