Xen Security Advisory 506 v2 (CVE-2026-62433) - correct buffer checks for DM_OP hypercalls

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

            Xen Security Advisory CVE-2026-62433 / XSA-506
                               version 2

              correct buffer checks for DM_OP hypercalls

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

Public release.

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

Parts of the DM_OP handling code assumes the caller has provided the
required number of buffers for the given operation without any checking
being done.  As a result, certain operations might access stack
rubble as structures are possibly uninitialized.

IMPACT
======

A device model of a HVM guest can gain insight on the contents of the
Xen stack, thus possibly leaking data from other guests contexts.

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

All Xen versions from 4.10 onwards are vulnerable.  Xen versions 4.9 and
earlier are not vulnerable.

Only entities controlling HVM guests can leverage the vulnerability.
These are device models running in either a stub domain or de-privileged
in Dom0.

MITIGATION
==========

Running only PV or PVH guests will avoid the vulnerability.

(Switching from a device model stub domain or a de-privileged device
model to a fully privileged Dom0 device model does NOT mitigate this
vulnerability.  Rather, it simply recategorises the vulnerability to
hostile management code, regarding it "as designed"; thus it merely
reclassifies these issues as "not a bug".  The security of a Xen system
using stub domains is still better than with a qemu-dm running as a Dom0
process.  Users and vendors of stub qemu dm systems should not change
their configuration to use a Dom0 QEMU process.)

RESOLUTION
==========

Applying the attached patch 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.

xsa506.patch           xen-unstable - Xen 4.17.x

$ sha256sum xsa506*
7fa79f0421eafa420f7af791ad35a96a769c945260d81419052611771347b411  xsa506.patch
$

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

Deployment of the patches and/or 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.

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/4UyVfoK9kFAmpomrwMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZNF4H/0c6JMsivAWWDIQ920Bwh7EEOKhMv3nGIrBqrN8/
TGKJNNoNQinhoQv9fnqwsHaiC8e49PNUJqTpEN8/o/b0obnl4Tw2JyUXFY1bZyaz
XNS85rkrUc0+Ue/Ka2464mmQ826TJXfaXG9CZYlC5cO/JtzX65ecMW4H7ju2tdnt
c9xK+I5kIQPwUwy3HUMrKFvWi+JIvpCzhuHYDH2iJDecmk42pOmnKtS54q6YO15n
c4xdn7aNyeECKQw4qUcjKC7zKRgrqFu5J3BlvXauZOkJCL50PK+OpWK6QV+fRNGy
N7dnY5w+1BMVrHywZI5iy8WqZtJoi6TOO1Gl0WcB07/vvJk=
=APkr
-----END PGP SIGNATURE-----

From 6c38823e8971fabd4d2e4d447c65b39f57b953e3 Mon Sep 17 00:00:00 2001
From: Roger Pau Monne <[email protected]>
Date: Tue, 14 Jul 2026 13:13:12 +0200
Subject: xen/dmop: check number of input buffers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The hypercall requires at least one input buffer, as both arch-specific
implementations of dm_op() unconditionally assume ->buf[0] to be valid (and
not stack rubble).

Additionally, XEN_DMOP_modified_memory requires two input buffers, yet the
code was assuming the second buffer to always be provided by the user when
checking for the number of extents.  In case the caller sets nr_bufs to 1,
the code in modified_memory() will read stack garbage as the size of the
buffer, thus allowing the caller some degree of insight on the contents of
the stack by probing whether the hypercall returns -EINVAL or -EFAULT as a
result of such bogus call.

This is XSA-506 / CVE-2026-62433.

Fixes: e3b93b3c5954 ("dmop: add xendevicemodel_modified_memory_bulk()")
Fixes: 85cb15dfe4d1 ("x86/hvm/dmop: only copy what is needed to/from the guest")
Signed-off-by: Roger Pau Monné <[email protected]>
Reviewed-by: Andrew Cooper <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
---
 xen/arch/x86/hvm/dm.c | 9 +++++++++
 xen/common/dm.c       | 3 +++
 2 files changed, 12 insertions(+)

diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 066498e07ea1..1f44fff12a21 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -494,6 +494,12 @@ int dm_op(const struct dmop_args *op_args)
         struct xen_dm_op_modified_memory *data =
             &op.u.modified_memory;
 
+        if ( op_args->nr_bufs != 2 )
+        {
+            rc = -EINVAL;
+            break;
+        }
+
         rc = modified_memory(d, op_args, data);
         const_op = !rc;
         break;
@@ -655,6 +661,9 @@ int compat_dm_op(
     unsigned int i;
     int rc;
 
+    if ( !nr_bufs )
+        return -ENODATA;
+
     if ( nr_bufs > ARRAY_SIZE(args.buf) )
         return -E2BIG;
 
diff --git a/xen/common/dm.c b/xen/common/dm.c
index 201b652deb7e..8689728ab7a3 100644
--- a/xen/common/dm.c
+++ b/xen/common/dm.c
@@ -26,6 +26,9 @@ long do_dm_op(
     struct dmop_args args;
     int rc;
 
+    if ( !nr_bufs )
+        return -ENODATA;
+
     if ( nr_bufs > ARRAY_SIZE(args.buf) )
         return -E2BIG;
 
-- 
2.53.0