Manuel Andreas

**Name of the Vulnerable Software and Affected Versions** Xen hypervisor versions prior to 4.7 **Description** The issue is related to the hypervisor's code for accelerating VGA memory accesses for HVM guests in "standard" mode. The locking mechanism involved has an unusual discipline, which can lead to a deadlock when emulating an instruction with two memory accesses that touch VGA memory. This behavior results in a problem when the lock is attempted to be re-acquired, causing a deadlock. The deadlock was previously found but analyzed incorrectly, and the fix was incomplete. The logic for this feature has been removed in staging since it was discovered to be accidentally disabled since Xen 4.7. **Recommendations** To resolve the issue, backport the removal of most of the feature related to VGA memory access acceleration for HVM guests in "standard" mode. As a temporary workaround, consider disabling the feature to minimize the risk of exploitation. Note that even with the feature disabled, the lock would still be acquired for any accesses to the VGA MMIO region. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Xen (affected versions not specified) **Description** The issue is related to the x86 HVM hypercall handler in the Xen hypervisor. HVM guests can switch freely between 64-bit and other modes, allowing them to set registers used to pass 32-bit-mode hypercall arguments to values outside of the range 32-bit code would be able to set them to. When processing of hypercalls takes a considerable amount of time, the hypervisor may choose to invoke a hypercall continuation, which involves putting updated hypercall arguments in respective registers. For guests not running in 64-bit mode, this further involves a certain amount of translation of the values. Unfortunately, internal sanity checking of these translated values assumes high halves of registers to always be clear when invoking a hypercall. When this is found not to be the case, it triggers a consistency check in the hypervisor and causes a crash. A HVM or PVH guest can cause a hypervisor crash, resulting in a Denial of Service (DoS) of the entire host. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** GNU Screen versions through 4.9.0 **Description** The issue allows local users to send a privileged SIGHUP signal to any PID, causing a denial of service or disruption of the target process. This occurs when GNU Screen is installed setuid or setgid, which is the default on platforms such as Arch Linux and FreeBSD. **Recommendations** For GNU Screen versions through 4.9.0, update to a version later than 4.9.0 to resolve the issue.