Information

Files

Advisory

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