远程 OracleVM 系统缺少必要修补程序来解决关键安全更新：

- xen：修复 guest_physmap_mark_populate_on_demand 的错误处理 “out”标签的唯一用户绕过必要的解锁，从而使调用程序能够锁定 Xen。此外，该函数从未打算被其自身的客户机调用，因此与其在代码路径中深入检查这样可能造成的其他潜在问题并调整上述错误路径中的（比如）非客户机 printk，不如禁止客户机访问它。最后，printk（考虑到其向日志发送垃圾信息的可能性，其更加不会使用 XENLOG_GUEST）被转换为 P2M_DEBUG，因为明显会首先添加调试。这是 XSA-30/CVE-2012-5514。
 (CVE-2012-5514)

- 恢复 XSA-30 / CVE-2012-5514 的版本 2 (CVE-2012-5514)

- memop：限制客户机指定的范围顺序 在此处允许未限制边界的顺序值会导致几乎未限制边界的循环和/或部分不完整的请求，尤其是在 PoD 代码中。populate_physmap、decrease_reservation 以及 memory_exchange 中的“in”中架构化添加的范围检查都可使用 PADDR_BITS - PAGE_SHIFT，并且被人为限制为 MAX_ORDER。这是 XSA-31/CVE-2012-5515。
 (CVE-2012-5515)

- xen：修复 guest_physmap_mark_populate_on_demand 的错误路径 “out”标签的唯一用户绕过必要的解锁，从而使调用程序能够锁定 Xen。这是 XSA-30/CVE-2012-5514。(CVE-2012-5514)

- xen：向 XENMEM_exchange 处理程序添加缺少的客户机地址范围检查 自从其出现 (3.0.3 iirc) 以来，此函数的处理程序就已在未首先对访问的空间进行范围检查（通过 guest_handle_okay）的情况下使用无地址范围检查的客户机内存访问器（即带两个下划线前缀的访问器），从而允许客户机访问并覆盖管理程序内存。这是 XSA-29/CVE-2012-5513。

- hvm：限制大型 HVM 操作批处理的大小 在未抢占的情况下为 HVMOP_track_dirty_vram 进行大型 p2m 更新会占用物理处理器。难以将抢占集成到 p2m 更新中，因此只需限制为 1GB，该大小对 15000 * 15000 * 32bpp 帧缓冲已足够。对于可抢占的 HVMOP_modified_memory 和 HVMOP_set_mem_type，添加必要的手段以处理抢占。这是 CVE-2012-5511/XSA-27。

x86/paging：不分配受用户控制的堆栈内存量。这是 XSA-27/CVE-2012-5511。

v2：提供 GB 的定义以修复 x86-32 编译。

- xen/common/grant_table.c gnttab：修复在版本之间切换时的内存释放 gnttab_unpopulate_status_frames 不完整地释放之前用作未从域的 xenpage_list 中删除的页面中的状态框架的页面，因此当这些页面未因相同或其他目的而再次得到分配时会造成后续的列表损坏。
 同样，grant_table_create 和 gnttab_grow_table 都会在发生错误时错误地清理 - 无法仅通过将已与客户机共享的页面传递到 free_xenheap_page 来释放它们。通过仅在所有分配都成功之后才共享页面来修复此问题。这是 CVE-2012-5510/XSA-26。(CVE-2012-5510)

检测

OracleVM 3.0：xen (OVMSA-2012-0056)

medium Nessus 插件 ID 79490

未找到变更日志