Bug 2266325 (CVE-2023-46841, XSA-451)

ISSUE DESCRIPTION
=================

Recent x86 CPUs offer functionality named Control-flow Enforcement
Technology (CET).  A sub-feature of this are Shadow Stacks (CET-SS).
CET-SS is a hardware feature designed to protect against Return Oriented
Programming attacks. When enabled, traditional stacks holding both data
and return addresses are accompanied by so called "shadow stacks",
holding little more than return addresses.  Shadow stacks aren't
writable by normal instructions, and upon function returns their
contents are used to check for possible manipulation of a return address
coming from the traditional stack.

In particular certain memory accesses need intercepting by Xen.  In
various cases the necessary emulation involves kind of replaying of
the instruction.  Such replaying typically involves filling and then
invoking of a stub.  Such a replayed instruction may raise an
exceptions, which is expected and dealt with accordingly.

Unfortunately the interaction of both of the above wasn't right:
Recovery involves removal of a call frame from the (traditional) stack.
The counterpart of this operation for the shadow stack was missing.

IMPACT
======

An unprivileged guest can cause a hypervisor crash, causing a Denial of
Service (DoS) of the entire host.

VULNERABLE SYSTEMS
==================

Xen 4.14 and onwards are vulnerable.  Xen 4.13 and older are not
vulnerable.

Only x86 systems with CET-SS enabled are vulnerable.  x86 systems with
CET-SS unavailable or disabled are not vulnerable.  Arm systems are not
vulnerable.  See
https://xenbits.xen.org/docs/latest/faq.html#tell-if-cet-is-active
for how to determine whether CET-SS is active.

Only HVM or PVH guests can leverage the vulnerability.  PV guests cannot
leverage the vulnerability.

MITIGATION
==========

While in principle it is possible to disable use of CET on capable
systems using the "cet=no-shstk" command line option, doing so disables
an important security feature and may therefore not be advisable.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate (set of) attached patch(es) 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.

xsa451-?.patch         xen-unstable
xsa451-4.18.patch      Xen 4.18.x
xsa451-4.17.patch      Xen 4.17.x
xsa451-4.16.patch      Xen 4.16.x
xsa451-4.15.patch      Xen 4.15.x

$ sha256sum xsa451*
446178a9a37646e62622988efffa3d1ffa0b579fc089ab79138507acfd3440c0  xsa451-1.patch
614ab6925ea60f36212f0cd01929f3a97161de1828040770792e146c170bfea2  xsa451-2.patch
ad529273d7dc97bff239f1727a9702eb24d41b723d2a3077a1fecc4684900f91  xsa451-3.patch
2c68480657220cfab92fe9821ce201ff7c9e0b541619a1add541f3d66fa13e9d  xsa451-4.15.patch
fa8ab72e61fae0130fb81b0a7ce508fdb3bcb3c800b0ab7684aa6595cbad88ea  xsa451-4.16.patch
e41cab6471586a5f50e10eb26895fec624cc6d8fd3b4ff71495466df8aaa19e5  xsa451-4.17.patch
d6b76a8db6c80c0684fc94becc2e23091c8f1dcbebc726438dbb1a6cde543335  xsa451-4.18.patch
$