GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel xen/privcmd: unrestricted hypercalls from an unprivileged domU break secure boot (XSA-482)

CVSS 8.2CVE-2026-31788Kernel, userspace & hypervisorcurated

Impact

The Xen privcmd driver let a root process in an unprivileged domU issue arbitrary hypercalls instead of only those targeting the guest it acts as device model for. Where the guest is booted with secure boot, that lets a root user modify kernel memory and so defeat the integrity guarantee secure boot is there to provide - the kernel can no longer be trusted to be the one that was verified. The fix reads the target domain from Xenstore at driver init when not running in dom0 and locks privcmd to that domain from the start, rather than relying on userspace to apply the restriction. For operators running GPU or accelerator workloads in Xen guests, this is an in-guest integrity break: it does not cross from domU to the hypervisor or to other guests, but it voids any attestation or lockdown story built on secure boot inside the VM. Tracked as XSA-482.

Who can reach it

Local, high privilege. Root inside an unprivileged Xen domU with access to /dev/xen/privcmd. Not reachable from an unprivileged user, not reachable remotely, and not applicable to dom0 or to non-Xen hosts.

What to do

Update the guest kernels to a stable release carrying the privcmd fix (five commits linked in the record) and reboot each affected domU. Until then, the exposure can be cut by not exposing /dev/xen/privcmd to guests that are not acting as a device model for another guest, or by not relying on in-guest secure boot as a security boundary against guest root. The record lists commits only, no fixed version numbers.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.