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