Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 832039 (CVE-2022-23033, CVE-2022-23034, CVE-2022-23035) - <app-emulation/xen-{4.15.1-r3,4.16.0-r2}: multiple vulnerabilities in Xen (CVE-2022-{23033,23034,23035})
Summary: <app-emulation/xen-{4.15.1-r3,4.16.0-r2}: multiple vulnerabilities in Xen (CV...
Status: CONFIRMED
Alias: CVE-2022-23033, CVE-2022-23034, CVE-2022-23035
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B3 [glsa? cleanup]
Keywords: PullRequest
Depends on: 833750
Blocks:
  Show dependency tree
 
Reported: 2022-01-25 12:50 UTC by filip ambroz
Modified: 2022-02-19 20:05 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description filip ambroz 2022-01-25 12:50:44 UTC
[Xen Security Advisory 393 v2 (CVE-2022-23033)]
URL: https://seclists.org/oss-sec/2022/q1/71

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.



[Xen Security Advisory 394 v3 (CVE-2022-23034)]
URL: https://seclists.org/oss-sec/2022/q1/72

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.

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
ee93797546ac9e82f98211366f9acc733332b0d5ab7ef73840c2acd2bb1439ca  xsa394-4.12.patch
$
Comment 1 filip ambroz 2022-01-25 12:55:09 UTC
Please also beware of the bug:

[Xen Security Advisory 395 v2 (CVE-2022-23035)]
URL: https://seclists.org/oss-sec/2022/q1/73

Insufficient cleanup of passed-through device IRQs

Not Affecting Xen versions in the portage tree
(Xen versions 4.6 and later are vulnerable. Xen versions 4.5 and earlier are not vulnerable.)
Comment 2 John Helmert III archtester Gentoo Infrastructure gentoo-dev Security 2022-01-26 14:02:23 UTC
(In reply to filip ambroz from comment #1)
> Please also beware of the bug:
> 
> [Xen Security Advisory 395 v2 (CVE-2022-23035)]
> URL: https://seclists.org/oss-sec/2022/q1/73
> 
> Insufficient cleanup of passed-through device IRQs
> 
> Not Affecting Xen versions in the portage tree
> (Xen versions 4.6 and later are vulnerable. Xen versions 4.5 and earlier are
> not vulnerable.)

Seems our versions are a bit higher than 4.6, though?
Comment 3 filip ambroz 2022-01-26 14:25:46 UTC
[Xen Security Advisory 395 v2 (CVE-2022-23035)]
URL: https://seclists.org/oss-sec/2022/q1/73

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

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
$
Comment 4 filip ambroz 2022-01-26 14:27:43 UTC
(In reply to John Helmert III from comment #2)
> (In reply to filip ambroz from comment #1)
> > Please also beware of the bug:
> > 
> > [Xen Security Advisory 395 v2 (CVE-2022-23035)]
> > URL: https://seclists.org/oss-sec/2022/q1/73
> > 
> > Insufficient cleanup of passed-through device IRQs
> > 
> > Not Affecting Xen versions in the portage tree
> > (Xen versions 4.6 and later are vulnerable. Xen versions 4.5 and earlier are
> > not vulnerable.)
> 
> Seems our versions are a bit higher than 4.6, though?

Obviously you are right :) All three bugs apply.
Thank you for pointing that out!
Comment 5 Larry the Git Cow gentoo-dev 2022-02-18 03:06:57 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=30103c3739d852d6b78be7ef9d64c480dd4eb5ad

commit 30103c3739d852d6b78be7ef9d64c480dd4eb5ad
Author:     Tomáš Mózes <hydrapolic@gmail.com>
AuthorDate: 2022-01-28 08:22:23 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2022-02-18 02:52:36 +0000

    app-emulation/xen: add upstream security patches
    
    Bug: https://bugs.gentoo.org/832039
    Signed-off-by: Tomáš Mózes <hydrapolic@gmail.com>
    Signed-off-by: Sam James <sam@gentoo.org>

 app-emulation/xen/Manifest             |   2 +
 app-emulation/xen/xen-4.15.1-r3.ebuild | 163 ++++++++++++++++++++++++++++++++
 app-emulation/xen/xen-4.16.0-r2.ebuild | 164 +++++++++++++++++++++++++++++++++
 3 files changed, 329 insertions(+)
Comment 6 John Helmert III archtester Gentoo Infrastructure gentoo-dev Security 2022-02-19 15:04:29 UTC
Thanks, please cleanup!