-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

     Xen Security Advisory CVE-2025-58147,CVE-2025-58148 / XSA-475
                               version 2

       x86: Incorrect input sanitisation in Viridian hypercalls

UPDATES IN VERSION 2
====================

Public release.

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

Some Viridian hypercalls can specify a mask of vCPU IDs as an input, in
one of three formats.  Xen has boundary checking bugs with all three
formats, which can cause out-of-bounds reads and writes while processing
the inputs.

 * CVE-2025-58147.  Hypercalls using the HV_VP_SET Sparse format can
   cause vpmask_set() to write out of bounds when converting the bitmap
   to Xen's format.

 * CVE-2025-58148.  Hypercalls using any input format can cause
   send_ipi() to read d->vcpu[] out-of-bounds, and operate on a wild
   vCPU pointer.

IMPACT
======

A buggy or malicious guest can cause Denial of Service (DoS) affecting
the entire host, information leaks, or elevation of privilege.

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

Xen versions 4.15 and newer are vulnerable.  Versions 4.14 and older are
not vulnerable.

Only x86 HVM guests which have Viridian enabled can leverage the
vulnerability.

With the `xl` toolstack, this means any `viridian=` setting in the VM's
configuration file.

Note - despite:

  `viridian=["!hcall_remote_tlb_flush", "!hcall_ipi", "!ex_processor_masks"]`

being documented to turns off the relevant functionality, this
configuration does not block the relevant hypercalls.

MITIGATION
==========

Not enabling Viridian will avoid the issuse.

CREDITS
=======

This issue was discovered by Teddy Astie of Vates

RESOLUTION
==========

Applying the appropriate set of attached patches 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.

xsa475-?.patch           xen-unstable - Xen 4.20.x
xsa475-4.19-?.patch      Xen 4.19.x - Xen 4.17.x

$ sha256sum xsa475*
25ba4933e4cf94e81d192f3ba522ec7b258c6e69015a43d169b0325e61957f42  xsa475-1.patch
d012541f99c69279b30554e8ea7a7da2790aaa6ff81b0d597f305e4498391369  xsa475-2.patch
6b820b116418e6fd376b6d23ede589e4f86fea4ea775e9afb5c631ceba44d05f  xsa475-4.19-1.patch
f94b48392179bc08f412ead900a91299ef3a27a6dd4f5fdcf7a152fd65d3a02b  xsa475-4.19-2.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches (but not mitigations) described above (or others
which are substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.

This is because the mitigations are guest visible changes, and hence could
give hints to users about the upcoming vulnerabilities.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

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/4UyVfoK9kFAmj3daEMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZnvgIAJzU/Bczr7/Gj3pIqop+rgDsoLw/PU2tGkwhumJQ
0lICxaHWlqrk8cL0y+Ll0nQV4DTwoZbhSm9Bz3S9ZKo6/Qby9YZzo0Tyt9U2OxNU
YTpiYGSwrSlCs8cpfj4gwKGzEZ0nNTBTVbAa9UfqIYcvNF4j/L0Tnl6cJOZ/xNhh
8BoH02j+vCF8B8ZInutJjHhKPtrmDta0/md9R4Ydrx4OrLlAoYA4hKnkOuBWfhHg
amL1aJ3vk9kNNkP6sO19Vnp5KTawnLGZwN95+FDlDGuh8n8ixKfURvZ9eK8Ycfir
naItP4wBkFC9ukzlvGtkwoHPDspxKjtFTYfNvVNvoV6JOWc=
=oSQZ
-----END PGP SIGNATURE-----