The Xen hypervisor project today released nine security patches that should be applied ASAP – particularly the one that stops guest virtual machines seizing control of host servers.

That vulnerability – XSA-148 – can be exploited by a paravirtualized guest to manipulate the memory layout of the underlying system, and ultimately compromise the host and all other virtual machines running on it. Which is bad. The open-source Qubes OS project, which relies on Xen to run apps and drivers in isolated compartments, has dissected the programming blunder, here.

It appears the seven-year-old Xen bug is caused by an entanglement of C macros, bit masking, and Intel x86's fiddly page table flags. First there's this line in Xen's x86 MMU code:

if ( unlikely(l2e_get_flags(nl2e) & L2_DISALLOW_MASK) )

...and then L2_DISALLOW_MASK is defined as:

#define L2_DISALLOW_MASK (base_disallow_mask & ~_PAGE_PSE)

...and base_disallow_mask is defined as:

base_disallow_mask = ~(_PAGE_PRESENT|_PAGE_RW|_PAGE_USER| _PAGE_ACCESSED|_PAGE_DIRTY|_PAGE_AVAIL);

...and by now you should be getting used to the x86-operating-system circle of Hell. It's possible, as an attacker, to evade these checks and flip the right bits to gain read-write access to the system's level one page table – the world map of the host's memory. It allows the guest to access any part of the system RAM.

It's game over at that point – and the Qubes OS crew, who strive to build a secure computing environment, are not happy.

"It is really shocking that such a bug has been lurking in the core of the hypervisor for so many years," the Qubes security team wrote.

"In our opinion the Xen project should rethink their coding guidelines and try to come up with practices and perhaps additional mechanisms that would not let similar flaws to plague the hypervisor ever again. Otherwise the whole project makes no sense, at least to those who would like to use Xen for security-sensitive work."

Here are the bug fixes in full:

XSA-153 : Denial of service. In a guest VM, an unprivileged user can crash the guest. Affects x86.

: Denial of service. In a guest VM, an unprivileged user can crash the guest. Affects x86. XSA-152 : Denial of service. A guest VM can spam the hypervisor console with messages. Affects x86.

: Denial of service. A guest VM can spam the hypervisor console with messages. Affects x86. XSA-151 : Denial of service. A malicious guest administrator can cause the host system to run out of memory. Affects x86.

: Denial of service. A malicious guest administrator can cause the host system to run out of memory. Affects x86. XSA-150 : Denial of service. A malicious HVM guest administrator could force the host to reboot. Affects x86.

: Denial of service. A malicious HVM guest administrator could force the host to reboot. Affects x86. XSA-149 : Denial of service. An attacker can very slowly cause a host to run out of memory. Affects x86 and ARM.

: Denial of service. An attacker can very slowly cause a host to run out of memory. Affects x86 and ARM. XSA-148 : Escalation of privilege. Malicious PV guest administrators can take over the host system. Affects x86.

: Escalation of privilege. Malicious PV guest administrators can take over the host system. Affects x86. XSA-147 : Denial of service. An attacker can cause the host to crash. Affects ARM.

: Denial of service. An attacker can cause the host to crash. Affects ARM. XSA-146 : Denial of service. A guest can spam messages to the hypervisor console. Affects ARM.

: Denial of service. A guest can spam messages to the hypervisor console. Affects ARM. XSA-145: Denial of service. Any guest can crash the host server. Affects ARM.

We warned of the Xen patch batch on Tuesday. The open-source hypervisor is used all over the place, particularly by cloud providers to host virtual machines – so if your VMs are restarted in the next few days, this'll be why. Amazon AWS, a big Xen user, said its systems are not affected, though. ®