OracleVM 3.0 : xen (OVMSA-2012-0056)
Medium Nessus Plugin ID 79490
SynopsisThe remote OracleVM host is missing one or more security updates.
DescriptionThe remote OracleVM system is missing necessary patches to address critical security updates :
- xen: fix error handling of guest_physmap_mark_populate_on_demand The only user of the 'out' label bypasses a necessary unlock, thus enabling the caller to lock up Xen. Also, the function was never meant to be called by a guest for itself, so rather than inspecting the code paths in depth for potential other problems this might cause, and adjusting e.g. the non-guest printk in the above error path, just disallow the guest access to it. Finally, the printk (considering its potential of spamming the log, the more that it's not using XENLOG_GUEST), is being converted to P2M_DEBUG, as debugging is what it apparently was added for in the first place. This is XSA-30 / CVE-2012-5514.
- Revert version 2 of XSA-30 / CVE-2012-5514 (CVE-2012-5514)
- memop: limit guest specified extent order Allowing unbounded order values here causes almost unbounded loops and/or partially incomplete requests, particularly in PoD code. The added range checks in populate_physmap, decrease_reservation, and the 'in' one in memory_exchange architecturally all could use PADDR_BITS
- PAGE_SHIFT, and are being artificially constrained to MAX_ORDER. This is XSA-31 / CVE-2012-5515.
- xen: fix error path of guest_physmap_mark_populate_on_demand The only user of the 'out' label bypasses a necessary unlock, thus enabling the caller to lock up Xen. This is XSA-30 / CVE-2012-5514. (CVE-2012-5514)
- xen: add missing guest address range checks to XENMEM_exchange handlers Ever since its existence (3.0.3 iirc) the handler for this has been using non address range checking guest memory accessors (i.e. the ones prefixed with two underscores) without first range checking the accessed space (via guest_handle_okay), allowing a guest to access and overwrite hypervisor memory. This is XSA-29 / CVE-2012-5513.
- hvm: Limit the size of large HVM op batches Doing large p2m updates for HVMOP_track_dirty_vram without preemption ties up the physical processor. Integrating preemption into the p2m updates is hard so simply limit to 1GB which is sufficient for a 15000 * 15000 * 32bpp framebuffer. For HVMOP_modified_memory and HVMOP_set_mem_type preemptible add the necessary machinery to handle preemption. This is CVE-2012-5511 / XSA-27.
x86/paging: Don't allocate user-controlled amounts of stack memory. This is XSA-27 / CVE-2012-5511.
v2: Provide definition of GB to fix x86-32 compile.
- xen/common/grant_table.c gnttab: fix releasing of memory upon switches between versions gnttab_unpopulate_status_frames incompletely freed the pages previously used as status frame in that they did not get removed from the domain's xenpage_list, thus causing subsequent list corruption when those pages did get allocated again for the same or another purpose.
Similarly, grant_table_create and gnttab_grow_table both improperly clean up in the event of an error - pages already shared with the guest can't be freed by just passing them to free_xenheap_page. Fix this by sharing the pages only after all allocations succeeded. This is CVE-2012-5510 / XSA-26. (CVE-2012-5510)
SolutionUpdate the affected xen / xen-devel / xen-tools packages.