drivers/xen/privcmd.c | 60 ++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 57 insertions(+), 3 deletions(-)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory XSA-482
version 2
Linux privcmd driver can circumvent kernel lockdown
UPDATES IN VERSION 2
====================
Public release.
ISSUE DESCRIPTION
=================
The Linux kernel's privcmd driver can be abused to circumvent kernel
lockdown (secure boot), e.g. by modifying page tables to enable user
mode to modify kernel memory.
The CNA covering Linux has refused to assign a CVE at this juncture.
IMPACT
======
An administrator of an unprivileged guest booted in secure mode is able
to perform actions on the kernel which should not be possible in secure
mode.
VULNERABLE SYSTEMS
==================
PV, PVH and HVM guests running Linux using secure boot are vulnerable.
BSD based systems are believed not to be vulnerable due to a lack of
secure boot support.
MITIGATION
==========
There is no known mitigation.
CREDITS
=======
This issue was discovered by Teddy Astie of Vates.
RESOLUTION
==========
Applying the set of attached patches resolves this issue.
xsa482-linux-?.patch Linux
$ sha256sum xsa482*
a4e67d2c773e2e13252337e4b64c08b342c0eb2e0e92271a79dc588ac34e7c3a xsa482-linux-1.patch
dd952c1fc49ceb47803b78e15cfe3f7f11a845b29c6b2a80afa7a9eaa60a00ec xsa482-linux-2.patch
$
DEPLOYMENT DURING EMBARGO
=========================
Deployment of patches or mitigations 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 on public cloud systems
is NOT permitted.
This is because the patches need to be applied to the guests.
Deployment is permitted only AFTER the embargo ends.
(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/4UyVfoK9kFAmnCffYMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZLUIIAIU0v7T3tT1Jc2UeanX2sj2aycfKjpCCoAxTtFcG
qKdhneXhKQ3ofWH3SSRmuNfA6L1jVPyh7bUYLMpNQp4WfsCUj0RNcjXhdxYIldTP
KLi+mhekZzjarClj+X9eQOQf0DaGGy1dG1SUfETHuumOcm7CVbRDKF9nXVv6g4Dd
CCnDuXjK2M9Q91shdDAUI7I41oQL3k85UTpPwwtAs1subKCJsgbKIBdikw3Bdm4c
TBkqTyjFCiLiLXcqcY7qQo/IcfJ9mn0z3Jc0M4V12Am6DdLrypO0LU3YcVRH3qT9
/5L5It2HKjoFRp+6yEb7yfBkavXQgaGwCSnROUC7dn41pM8=
=mibo
-----END PGP SIGNATURE-----
From 265f2052fcb52b9e26e146789359f4522ceedd1b Mon Sep 17 00:00:00 2001
From: Juergen Gross <jgross@suse.com>
Date: Thu, 9 Oct 2025 16:54:58 +0200
Subject: [PATCH v3 1/2] xen/privcmd: restrict usage in unprivileged domU
The Xen privcmd driver allows to issue arbitrary hypercalls from
user space processes. This is normally no problem, as access is
usually limited to root and the hypervisor will deny any hypercalls
affecting other domains.
In case the guest is booted using secure boot, however, the privcmd
driver would be enabling a root user process to modify e.g. kernel
memory contents, thus breaking the secure boot feature.
The only known case where an unprivileged domU is really needing to
use the privcmd driver is the case when it is acting as the device
model for another guest. In this case all hypercalls issued via the
privcmd driver will target that other guest.
Fortunately the privcmd driver can already be locked down to allow
only hypercalls targeting a specific domain, but this mode can be
activated from user land only today.
The target domain can be obtained from Xenstore, so when not running
in dom0 restrict the privcmd driver to that target domain from the
beginning, resolving the potential problem of breaking secure boot.
This is XSA-482 / CVE ???
Reported-by: Teddy Astie <teddy.astie@vates.tech>
Fixes: 1c5de1939c20 ("xen: add privcmd driver")
Signed-off-by: Juergen Gross <jgross@suse.com>
---
drivers/xen/privcmd.c | 60 ++++++++++++++++++++++++++++++++++++++++---
1 file changed, 57 insertions(+), 3 deletions(-)
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 1759cc18753f..a83bad69f4f2 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -12,6 +12,7 @@
#include <linux/eventfd.h>
#include <linux/file.h>
#include <linux/kernel.h>
+#include <linux/kstrtox.h>
#include <linux/module.h>
#include <linux/mutex.h>
#include <linux/poll.h>
@@ -30,7 +31,9 @@
#include <linux/seq_file.h>
#include <linux/miscdevice.h>
#include <linux/moduleparam.h>
+#include <linux/notifier.h>
#include <linux/virtio_mmio.h>
+#include <linux/wait.h>
#include <asm/xen/hypervisor.h>
#include <asm/xen/hypercall.h>
@@ -46,6 +49,7 @@
#include <xen/page.h>
#include <xen/xen-ops.h>
#include <xen/balloon.h>
+#include <xen/xenbus.h>
#ifdef CONFIG_XEN_ACPI
#include <xen/acpi.h>
#endif
@@ -72,6 +76,11 @@ struct privcmd_data {
domid_t domid;
};
+/* DOMID_INVALID implies no restriction */
+static domid_t target_domain = DOMID_INVALID;
+static bool restrict_wait;
+static DECLARE_WAIT_QUEUE_HEAD(restrict_wait_wq);
+
static int privcmd_vma_range_is_mapped(
struct vm_area_struct *vma,
unsigned long addr,
@@ -1563,13 +1572,16 @@ static long privcmd_ioctl(struct file *file,
static int privcmd_open(struct inode *ino, struct file *file)
{
- struct privcmd_data *data = kzalloc_obj(*data);
+ struct privcmd_data *data;
+
+ if (wait_event_interruptible(restrict_wait_wq, !restrict_wait) < 0)
+ return -EINTR;
+ data = kzalloc_obj(*data);
if (!data)
return -ENOMEM;
- /* DOMID_INVALID implies no restriction */
- data->domid = DOMID_INVALID;
+ data->domid = target_domain;
file->private_data = data;
return 0;
@@ -1662,6 +1674,45 @@ static struct miscdevice privcmd_dev = {
.fops = &xen_privcmd_fops,
};
+static int init_restrict(struct notifier_block *notifier,
+ unsigned long event,
+ void *data)
+{
+ char *target;
+ unsigned int domid;
+
+ /* Default to an guaranteed unused domain-id. */
+ target_domain = DOMID_IDLE;
+
+ target = xenbus_read(XBT_NIL, "target", "", NULL);
+ if (IS_ERR(target) || kstrtouint(target, 10, &domid)) {
+ pr_err("No target domain found, blocking all hypercalls\n");
+ goto out;
+ }
+
+ target_domain = domid;
+
+ out:
+ if (!IS_ERR(target))
+ kfree(target);
+
+ restrict_wait = false;
+ wake_up_all(&restrict_wait_wq);
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block xenstore_notifier = {
+ .notifier_call = init_restrict,
+};
+
+static void __init restrict_driver(void)
+{
+ restrict_wait = true;
+
+ register_xenstore_notifier(&xenstore_notifier);
+}
+
static int __init privcmd_init(void)
{
int err;
@@ -1669,6 +1720,9 @@ static int __init privcmd_init(void)
if (!xen_domain())
return -ENODEV;
+ if (!xen_initial_domain())
+ restrict_driver();
+
err = misc_register(&privcmd_dev);
if (err != 0) {
pr_err("Could not register Xen privcmd device\n");
--
2.53.0
From 6f6918fe1dd4590e00ff9590086fab08d928405b Mon Sep 17 00:00:00 2001
From: Juergen Gross <jgross@suse.com>
Date: Tue, 14 Oct 2025 13:28:15 +0200
Subject: [PATCH v3 2/2] xen/privcmd: add boot control for restricted usage in
domU
When running in an unprivileged domU under Xen, the privcmd driver
is restricted to allow only hypercalls against a target domain, for
which the current domU is acting as a device model.
Add a boot parameter "unrestricted" to allow all hypercalls (the
hypervisor will still refuse destructive hypercalls affecting other
guests).
Make this new parameter effective only in case the domU wasn't started
using secure boot, as otherwise hypercalls targeting the domU itself
might result in violating the secure boot functionality.
This is achieved by adding another lockdown reason, which can be
tested to not being set when applying the "unrestricted" option.
This is part of XSA-482 / CVE-???
Signed-off-by: Juergen Gross <jgross@suse.com>
---
drivers/xen/privcmd.c | 13 +++++++++++++
include/linux/security.h | 1 +
security/security.c | 1 +
3 files changed, 15 insertions(+)
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index a83bad69f4f2..bbf9ee21306c 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -32,6 +32,7 @@
#include <linux/miscdevice.h>
#include <linux/moduleparam.h>
#include <linux/notifier.h>
+#include <linux/security.h>
#include <linux/virtio_mmio.h>
#include <linux/wait.h>
@@ -72,6 +73,11 @@ module_param_named(dm_op_buf_max_size, privcmd_dm_op_buf_max_size, uint,
MODULE_PARM_DESC(dm_op_buf_max_size,
"Maximum size of a dm_op hypercall buffer");
+static bool unrestricted;
+module_param(unrestricted, bool, 0);
+MODULE_PARM_DESC(unrestricted,
+ "Don't restrict hypercalls to target domain if running in a domU");
+
struct privcmd_data {
domid_t domid;
};
@@ -1708,6 +1714,13 @@ static struct notifier_block xenstore_notifier = {
static void __init restrict_driver(void)
{
+ if (unrestricted) {
+ if (security_locked_down(LOCKDOWN_XEN_USER_ACTIONS))
+ pr_warn("Kernel is locked down, parameter \"unrestricted\" ignored\n");
+ else
+ return;
+ }
+
restrict_wait = true;
register_xenstore_notifier(&xenstore_notifier);
diff --git a/include/linux/security.h b/include/linux/security.h
index 83a646d72f6f..ee88dd2d2d1f 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -145,6 +145,7 @@ enum lockdown_reason {
LOCKDOWN_BPF_WRITE_USER,
LOCKDOWN_DBG_WRITE_KERNEL,
LOCKDOWN_RTAS_ERROR_INJECTION,
+ LOCKDOWN_XEN_USER_ACTIONS,
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_KCORE,
LOCKDOWN_KPROBES,
diff --git a/security/security.c b/security/security.c
index 67af9228c4e9..a26c1474e2e4 100644
--- a/security/security.c
+++ b/security/security.c
@@ -61,6 +61,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX + 1] = {
[LOCKDOWN_BPF_WRITE_USER] = "use of bpf to write user RAM",
[LOCKDOWN_DBG_WRITE_KERNEL] = "use of kgdb/kdb to write kernel RAM",
[LOCKDOWN_RTAS_ERROR_INJECTION] = "RTAS error injection",
+ [LOCKDOWN_XEN_USER_ACTIONS] = "Xen guest user action",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_KCORE] = "/proc/kcore access",
[LOCKDOWN_KPROBES] = "use of kprobes",
--
2.53.0
On Tue, Mar 24, 2026 at 12:05:44PM +0000, Xen.org security team wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Xen Security Advisory XSA-482 > version 2 > > Linux privcmd driver can circumvent kernel lockdown > > UPDATES IN VERSION 2 > ==================== > > Public release. > > ISSUE DESCRIPTION > ================= > > The Linux kernel's privcmd driver can be abused to circumvent kernel > lockdown (secure boot), e.g. by modifying page tables to enable user > mode to modify kernel memory. > > The CNA covering Linux has refused to assign a CVE at this juncture. This is now assigned to CVE-2026-31788 thanks, greg k-h
On Tue, Mar 24, 2026 at 01:16:08PM +0100, Greg KH wrote: > On Tue, Mar 24, 2026 at 12:05:44PM +0000, Xen.org security team wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Xen Security Advisory XSA-482 > > version 2 > > > > Linux privcmd driver can circumvent kernel lockdown > > > > UPDATES IN VERSION 2 > > ==================== > > > > Public release. > > > > ISSUE DESCRIPTION > > ================= > > > > The Linux kernel's privcmd driver can be abused to circumvent kernel > > lockdown (secure boot), e.g. by modifying page tables to enable user > > mode to modify kernel memory. > > > > The CNA covering Linux has refused to assign a CVE at this juncture. > > This is now assigned to CVE-2026-31788 And, to be more clear, the kernel CNA should have given you a CVE earlier, sorry about that, that was my fault. We had been "burned" by other groups/companies asking for CVEs "ahead of time" for Linux for things that turned out to be wrong or not needing a CVE at all at the same time you all asked for one, so I reacted much harsher here than you all deserved by saying we would assign one once the issue was public. I should have trusted you as obviously you know what you are doing here and should have gotten a CVE for your accounting earlier. Again, my fault, sorry about that, if you all need one in the future for any issue, we will assign it ahead of time. greg k-h
Hi Greg, On 24.03.26 13:31, Greg KH wrote: > On Tue, Mar 24, 2026 at 01:16:08PM +0100, Greg KH wrote: >> On Tue, Mar 24, 2026 at 12:05:44PM +0000, Xen.org security team wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> Xen Security Advisory XSA-482 >>> version 2 >>> >>> Linux privcmd driver can circumvent kernel lockdown >>> >>> UPDATES IN VERSION 2 >>> ==================== >>> >>> Public release. >>> >>> ISSUE DESCRIPTION >>> ================= >>> >>> The Linux kernel's privcmd driver can be abused to circumvent kernel >>> lockdown (secure boot), e.g. by modifying page tables to enable user >>> mode to modify kernel memory. >>> >>> The CNA covering Linux has refused to assign a CVE at this juncture. >> >> This is now assigned to CVE-2026-31788 > > And, to be more clear, the kernel CNA should have given you a CVE > earlier, sorry about that, that was my fault. We had been "burned" by > other groups/companies asking for CVEs "ahead of time" for Linux for > things that turned out to be wrong or not needing a CVE at all at the > same time you all asked for one, so I reacted much harsher here than you > all deserved by saying we would assign one once the issue was public. I > should have trusted you as obviously you know what you are doing here > and should have gotten a CVE for your accounting earlier. > > Again, my fault, sorry about that, if you all need one in the future for > any issue, we will assign it ahead of time. Thanks for the notice. Such things happen as nobody is perfect. Stay tuned for future CVE requests. :-) Juergen
On 24/03/2026 12:16 pm, Greg KH wrote: > On Tue, Mar 24, 2026 at 12:05:44PM +0000, Xen.org security team wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Xen Security Advisory XSA-482 >> version 2 >> >> Linux privcmd driver can circumvent kernel lockdown >> >> UPDATES IN VERSION 2 >> ==================== >> >> Public release. >> >> ISSUE DESCRIPTION >> ================= >> >> The Linux kernel's privcmd driver can be abused to circumvent kernel >> lockdown (secure boot), e.g. by modifying page tables to enable user >> mode to modify kernel memory. >> >> The CNA covering Linux has refused to assign a CVE at this juncture. > This is now assigned to CVE-2026-31788 Thankyou. I'll send out an update. ~Andrew
© 2016 - 2026 Red Hat, Inc.