Information

AdvisoryXSA-396
Public release 2022-03-10 10:54
Updated 2023-12-15 15:35
Version 4
CVE(s) CVE-2022-23036 CVE-2022-23037 CVE-2022-23038 CVE-2022-23039 CVE-2022-23040 CVE-2022-23041 CVE-2022-23042
Title Linux PV device frontends vulnerable to attacks by backends

Files

advisory-396.txt (signed advisory file)
xsa396-linux-01.patch
xsa396-linux-02.patch
xsa396-linux-03.patch
xsa396-linux-04.patch
xsa396-linux-05.patch
xsa396-linux-06.patch
xsa396-linux-07.patch
xsa396-linux-08.patch
xsa396-linux-09.patch
xsa396-linux-10.patch
xsa396-linux-11.patch
xsa396-linux-12.patch

Advisory


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

      Linux PV device frontends vulnerable to attacks by backends

UPDATES IN VERSION 4
====================

Normalize version tags

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

$ 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+MiLBRfRHX6gGCng/4UyVfoK9kFAmV8b/wMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZSOgH/3mALvB/jKbsaT2jMjBqq2jH5HUxBkg4oWv7A0eu
w/9i5oiZX6Zp8ynFpR5VMYW4rwMwmpvx+3T7Km8/fkjaztvdpxj9003/7qYr+bJV
qKC+6RzOEZ/iOssqa01869ij0KsaJl0n9kIuVXVab9b+sJlb5g63F/Mcy+JeuYKn
mJWPurUO1ZSiIK5R05uKWPRxNZa9TCUU8EvLRaa/GGLdro1n/OQv+3ukMHG1o+Kb
sHFD6Pn1jlCvmZmy+gBakIMehT6InpqvBtrJa9kPmwbKMYDYlBduN+t/J+m63lQR
mTIlYQvbOwK26PC/EXOhugV29GZxdgc228Nd5wsIKjL51m0=
=fpk1
-----END PGP SIGNATURE-----


Xenproject.org Security Team