[<prev] [next>] [day] [month] [year] [list]
Message-Id: <E1o8hHq-0004Es-Ry@xenbits.xenproject.org>
Date: Tue, 05 Jul 2022 12:04:14 +0000
From: Xen.org security team <security@....org>
To: xen-announce@...ts.xen.org, xen-devel@...ts.xen.org,
xen-users@...ts.xen.org, oss-security@...ts.openwall.com
CC: Xen.org security team <security-team-members@....org>
Subject: Xen Security Advisory 403 v3 (CVE-2022-26365,CVE-2022-33740,CVE-2022-33741,CVE-2022-33742)
- Linux disk/nic frontends data leaks
-----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-?.patch Xen 4.16.x - Xen 4.15.x
xsa403/xsa403-4.14-?.patch Xen 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 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/4UyVfoK9kFAmLEFf0MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZSVkIALkao7hSqBVJhnVifpXpLn+mxfECoI6lgQ1sphz6
oJ7U2QxuI6j6gVSUPk3GglYjKurGBYZjBAX6fBU8po9Zdagz/iuOXCif41NHobP8
POscgXMjKR4HPE8liXNYzSbTAbn7qiyNCxBO5yGK/jPMIC8K9+0ed+9ese6VVXSj
4buiqlkLb9FP5xTCGbtt/raZoGVVRx+LLhwC8dlNXllEvI1cJIK18pfnPF+ZUQwL
kXAx2figt3ZE1yNVv4Efnp2bMvv/XUGNU6X/ONP7wCKChzTOGdMyPMBJ1r73ceAn
TSvVuWDBoiWCLVIY1leTjRx9xxbQq84htGG68i8nQrHckz8=
=Wl2G
-----END PGP SIGNATURE-----
Download attachment "xsa403/xsa403-1.patch" of type "application/octet-stream" (10581 bytes)
Download attachment "xsa403/xsa403-2.patch" of type "application/octet-stream" (2419 bytes)
Download attachment "xsa403/xsa403-4.14-1.patch" of type "application/octet-stream" (2113 bytes)
Download attachment "xsa403/xsa403-4.14-2.patch" of type "application/octet-stream" (10634 bytes)
Download attachment "xsa403/xsa403-4.16-1.patch" of type "application/octet-stream" (2122 bytes)
Download attachment "xsa403/xsa403-4.16-2.patch" of type "application/octet-stream" (10814 bytes)
Download attachment "xsa403/xsa403-linux-1.patch" of type "application/octet-stream" (2092 bytes)
Download attachment "xsa403/xsa403-linux-2.patch" of type "application/octet-stream" (1281 bytes)
Download attachment "xsa403/xsa403-linux-3.patch" of type "application/octet-stream" (4203 bytes)
Download attachment "xsa403/xsa403-linux-4.patch" of type "application/octet-stream" (8040 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
