xen: multiple vulnerabilities
| Package(s): | Xen | CVE #(s): | CVE-2015-4163 CVE-2015-4164 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | June 12, 2015 | Updated: | June 24, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Xen advisories: CVE-2015-4163 - With the introduction of version 2 grant table operations, a version check became necessary for most grant table related hypercalls. The GNTTABOP_swap_grant_ref call was lacking such a check. As a result, the subsequent code behaved as if version 2 was in use, when a guest issued this hypercall without a prior GNTTABOP_setup_table or GNTTABOP_set_version. The effect is a possible NULL pointer dereferences. However, this cannot be exploited to elevate privileges of the attacking domain, as the maximum memory address that can be wrongly accessed this way is bounded to far below the start of hypervisor memory. CVE-2015-4164 - A buggy loop in Xen's compat_iret() function iterates the wrong way around a 32-bit index. Any 32-bit PV guest kernel can trigger this vulnerability by attempting a hypercall_iret with EFLAGS.VM set. Given the use of __get/put_user(), and that the virtual addresses in question are contained within the lower canonical half, the guest cannot clobber any hypervisor data. Instead, Xen will take up to 2^33 pagefaults, in sequence, effectively hanging the host. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||