Last updated 24 July 2024
pyGrub bootloader used to boot Xen para-virtualized guests did not have support for password command as supported by normal grub. If this option was used in grub.conf, it did not restrict users with access to para-virtualized guest's console from booting guest or changing kernel boot parameters without providing configured password. This could allow user with access to VMs console to get root privileges on the guest's operating system.
Upstream patches: ----------------- http://xenbits.xensource.com/xen-unstable.hg?rev/8f783adc0ee3 http://xenbits.xensource.com/staging/xen-unstable.hg?rev/a28c9c2fa8de http://xenbits.xensource.com/xen-unstable.hg?rev/e513d565c8f1 http://xenbits.xensource.com/xen-unstable.hg?rev/67f1b8b32585 http://xenbits.xensource.com/xen-unstable.hg?rev/168f0cfeded0
CVE Request: ------------ http://www.openwall.com/lists/oss-security/2009/09/25/1
Off-by-one error in the addrok macro in Xen 3.3 and earlier allows local 64 bit PV guest administrators to cause a denial of service (host crash) via unspecified hypercalls that ignore virtual-address bits.
A bug was found in the way Xen handles instruction emulation during VM exits. Malicious guest user space process running in SMP guest can trick the emulator into reading different instruction than the one that caused the VM exit. To do so it should run legitimate instruction that causes VM exit in one thread and replace this instruction to another one from second thread. An unprivileged guest user can potentially use this flaw to crash the host.
-------------------------------------------------------------
Original name: xen: svvp Disable Enable With IO will reboot the host which CPU is AMD
Description of problem: svvp Disable Enable With IO will reboot the host
svvp "Disable Enable with IO"'s child job "Driver Verifier -Enable"'s child job "Reboot System Under Test" should only reboot the guest , but when the guest prepare to enter the desktop after reboot , the host (SUT) will reboot .
Version-Release number of selected component (if applicable): xen-3.0.3-129.el5 kernel-xen-2.6.18-257.el5 xenpv-win-1.3.4-9.el5
How reproducible: 100%
Steps to Reproduce: 1. run the Disable Enable With IO 2. 3. Actual results: host will reboot
Expected results: host should not reboot
Additional info: Sometimes the guest even do not run the disable and enable jobs ,the host will reboot when I reboot the guest which run the disable and enable job once.
Xen, possibly before 4.0.2, allows local 64-bit PV guests to cause a denial of service (host crash) by specifying user mode execution without user-mode pagetables.
The guestphysmapmarkpopulateondemand function in Xen 4.2 and earlier does not properly unlock the subject GFNs when checking if they are in use, which allows local guest HVM administrators to cause a denial of service (hang) via unspecified vectors.
The XENMEMexchange handler in Xen 4.2 and earlier does not properly check the memory address, which allows local PV guest OS administrators to cause a denial of service (crash) or possibly gain privileges via unspecified vectors that overwrite memory in the hypervisor reserved range.
The (1) XENMEMdecreasereservation, (2) XENMEMpopulatephysmap, and (3) XENMEMexchange hypercalls in Xen 4.2 and earlier allow local guest administrators to cause a denial of service (long loop and hang) via a crafted extentorder value.
Xen 3.0.3 through 4.1.x (possibly 4.1.6.1), 4.2.x (possibly 4.2.3), and 4.3.x (possibly 4.3.1) does not properly prevent access to hypercalls, which allows local guest users to gain privileges via a crafted application running in ring 1 or 2.
The outs instruction emulation in Xen 3.1.x, 4.2.x, 4.3.x, and earlier, when using FS: or GS: segment override, uses an uninitialized variable as a segment base, which allows local 64-bit PV guests to obtain sensitive information (hypervisor stack content) via unspecified vectors related to stale data in a segment register.
Xen 4.3.x and earlier does not properly handle certain errors, which allows local HVM guests to obtain hypervisor stack memory via a (1) port or (2) memory mapped I/O write or (3) other unspecified operations related to addresses without associated memory.
Xen 4.2.x, 4.1.x, and earlier, when the hypervisor is running "under memory pressure" and the Xen Security Module (XSM) is enabled, uses the wrong ordering of operations when extending the per-domain event channel tracking table, which causes a use-after-free and allows local guest kernels to inject arbitrary events and gain privileges via unspecified vectors.
The x86emulate function in arch/x86/x86emulate/x86emulate.c in Xen 4.4.x and earlier does not properly check supervisor mode permissions, which allows local HVM users to cause a denial of service (guest crash) or gain guest kernel mode privileges via vectors involving an (1) HLT, (2) LGDT, (3) LIDT, or (4) LMSW instruction.