CVE-2026-31788

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen/privcmd: restrict usage in unprivileged domU<br /> <br /> The Xen privcmd driver allows to issue arbitrary hypercalls from<br /> user space processes. This is normally no problem, as access is<br /> usually limited to root and the hypervisor will deny any hypercalls<br /> affecting other domains.<br /> <br /> In case the guest is booted using secure boot, however, the privcmd<br /> driver would be enabling a root user process to modify e.g. kernel<br /> memory contents, thus breaking the secure boot feature.<br /> <br /> The only known case where an unprivileged domU is really needing to<br /> use the privcmd driver is the case when it is acting as the device<br /> model for another guest. In this case all hypercalls issued via the<br /> privcmd driver will target that other guest.<br /> <br /> Fortunately the privcmd driver can already be locked down to allow<br /> only hypercalls targeting a specific domain, but this mode can be<br /> activated from user land only today.<br /> <br /> The target domain can be obtained from Xenstore, so when not running<br /> in dom0 restrict the privcmd driver to that target domain from the<br /> beginning, resolving the potential problem of breaking secure boot.<br /> <br /> This is XSA-482<br /> <br /> ---<br /> V2:<br /> - defer reading from Xenstore if Xenstore isn&amp;#39;t ready yet (Jan Beulich)<br /> - wait in open() if target domain isn&amp;#39;t known yet<br /> - issue message in case no target domain found (Jan Beulich)