CVE-2026-31788
Received Received - Intake
Privilege Escalation via Xen privcmd Driver in Unprivileged domU

Publication date: 2026-03-25

Last updated on: 2026-04-24

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: 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 --- V2: - defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich) - wait in open() if target domain isn't known yet - issue message in case no target domain found (Jan Beulich)
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-25
Last Modified
2026-04-24
Generated
2026-05-07
AI Q&A
2026-03-26
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 15 associated CPEs
Vendor Product Version / Range
linux linux_kernel 2.6.37
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 6.2 (inc) to 6.6.130 (exc)
linux linux_kernel From 5.11 (inc) to 5.15.203 (exc)
linux linux_kernel From 5.16 (inc) to 6.1.167 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.78 (exc)
linux linux_kernel From 6.13 (inc) to 6.18.20 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.10 (exc)
linux linux_kernel From 2.6.37.1 (inc) to 5.10.253 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
How can this vulnerability be detected on my network or system? Can you suggest some commands?

There is no specific information provided in the available resources or CVE description about detection methods or commands to identify this vulnerability on a network or system.


Can you explain this vulnerability to me?

CVE-2026-31788 is a vulnerability in the Linux kernel's privcmd driver used in Xen virtual machines. The privcmd driver normally allows user space processes to issue hypercalls, which are usually restricted to root and limited by the hypervisor. However, when a guest VM is booted using secure boot, this vulnerability allows an unprivileged user in the guest to exploit the privcmd driver to modify kernel memory by altering page tables. This breaks the secure boot protections that are supposed to prevent such modifications.

The vulnerability arises because the privcmd driver does not sufficiently restrict hypercalls from unprivileged domains (domU). Although the driver can be locked down to restrict hypercalls to a specific target domain, this lockdown was only configurable from user space, which could be bypassed. The fix involves restricting the privcmd driver to only allow hypercalls targeting the correct domain from the start, preventing unauthorized kernel memory modifications.


How can this vulnerability impact me? :

This vulnerability can allow an unprivileged user within a Linux guest virtual machine running in secure boot mode to bypass kernel lockdown protections. Specifically, it enables the user to modify kernel memory by changing page tables, which should normally be protected under secure boot.

The impact is significant because it breaks the security guarantees provided by secure boot, potentially allowing privilege escalation, unauthorized code execution, or other malicious activities within the guest VM. This could compromise the integrity and security of the virtual machine and any sensitive data or operations it handles.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability can be mitigated by applying the patches provided in Xen Security Advisory XSA-482, specifically xsa482-linux-1.patch and xsa482-linux-2.patch.

These patches prevent the privcmd driver from bypassing kernel lockdown mechanisms such as secure boot.

Deployment of these patches was embargoed until March 24, 2026, and was restricted to organizations on the Xen Project Security Issues Predisclosure List.

After the embargo expiration, patch deployment is permitted and should be applied to guest virtual machines running Linux with secure boot enabled.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

CVE-2026-31788 allows an unprivileged user in a guest virtual machine running Linux with secure boot enabled to bypass kernel lockdown protections and modify kernel memory. This undermines the integrity guarantees provided by secure boot, potentially exposing sensitive system components to unauthorized modification.

Such a vulnerability could impact compliance with security-focused regulations and standards like GDPR and HIPAA, which require protection of system integrity and prevention of unauthorized access to sensitive data. By enabling kernel memory modification, this vulnerability could facilitate unauthorized data access or tampering, thereby increasing the risk of non-compliance with these regulations.

However, there is no explicit mention in the provided resources about direct compliance implications or guidance on regulatory impact. The primary focus is on the technical security risk and the need to apply patches to mitigate the vulnerability.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart