QEMU VGA device model (hw/display/vga.c) - banked access to video memory: 'Dark Portal' - the guest sets the VGA bank

Impact

'Dark Portal' - the guest sets the VGA bank register, then changes the access mode so the bounds check and the actual access disagree, and writes past the video memory window into the QEMU process. That yields arbitrary code execution on the host with the device model's privileges; without a stub domain on Xen, that is dom0. Relevant to GPU infrastructure because the emulated display device is present in essentially every VM regardless of whether the tenant has a real GPU - operators who assume 'we do not give tenants graphics' still ship an emulated VGA adapter to every guest, and it is one of the oldest and least-reviewed device models in QEMU.

Who can reach it

Guest OS user or administrator - the tenant - writing to standard VGA registers and the video memory window. No special device assignment required.

What to do

Update QEMU (fixed in the 2.6 cycle) or apply the XSA-179 patches, then restart every guest so it picks up the new device model - QEMU cannot be patched under a running VM. Live migration to a patched host is the way to do this without tenant-visible downtime, which is precisely the option you do not have for guests holding passed-through GPUs. Removing the emulated VGA adapter from guest configurations where it is not needed eliminates the surface outright and is the cheaper move for a fleet of headless compute VMs.

References