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

- libxc：builder：限制内核/ramdisk 的最大大小。
 允许用户提供任意大小的内核（尤其是在解压缩过程中）可用尽 dom0 内存，从而导致 builder 进程中的虚拟地址空间耗尽或者导致分配失败/OOM 终止 toolstack 和不相关的进程。我们在为 pvgrub 构建 stub 域时禁用这些检查，因为这会使用客户机自己的内存并且是孤立的。自 14954:58205257517d（Xen 3.1.0 及后续版本）起，解压缩 gzip 压缩的内核及 ramdisk 是安全的。这是 XSA-25/CVE-2012-4544。此外，还在各种解压缩例程中进行明确的缓冲区溢出检查。由于代码的其他属性，已经排除这些问题的可能性，但为双重保障仍进行检查。

[包括用于 CVE-2012-2625 的 25589:60f09d1ab1fe] (CVE-2012-4544)

- compat/gnttab：防止压缩代码 c/s 20281:95ea2052b41b 中的无限循环，此问题会引入授予表版本 2 超级调用会引入一个漏洞，导致压缩超级调用处理程序进入无限循环。
 如果启用监视程序，则 Xen 会在超时之后终止。这是安全问题，XSA-24/CVE-2012-4539。(CVE-2012-4539)

- xen/mm/shadow：在解除挂钩顶级页表之前，先检查它们是否存在。如果访客在调用 HVMOP_pagetable_dying 时没有完全填充其顶级 PAE 条目，则卷影代码会尝试从 MFN 0 解除挂钩条目。添加检查以避免此情况。此问题由 c/s 21239:b9d2db109cf5 引入。这是安全问题，XSA-23/CVE-2012-4538。(CVE-2012-4538)

- x86/physmap：防止错误地更新 m2p 映射在特定条件下（例如内存不足），set_p2m_entry 会失败。当前，p2m 和 m2p 表不同步，因为在 p2m 更新失败之后仍会更新 m2p 表。如果发生此情况，则后续访客调用的内存操作可导致 BUG 和 ASSERT 终止 Xen。仅在成功更新 p2m 时通过更新 m2p 表来修复此问题。这是安全问题，XSA-22/CVE-2012-4537。
 (CVE-2012-4537)

- x86/physdev：来自客户机的范围检查 pirq 参数。否则 Xen 将超出 struct domain.arch.pirq_emuirq 数组的两端进行读取，通常导致致命页面错误。此漏洞由 c/s 23241:d21100f1d00e 引入，它添加了对 domain_pirq_to_emuirq 的调用，后者在进行范围检查之前使用客户机提供的 pirq 值，并且此漏洞已被 c/s 23573:584c2e5e03d9 修复，将 domain_pirq_to_emuirq 宏的行为更改为使用 radix 树而非平面数组。这是 XSA-21/CVE-2012-4536。
 (CVE-2012-4536)

- VCPU/timers：防止在计算中出现溢出，会导致 DoS 漏洞 VCPU 周期定时器的定时器操作用于计算下一个过期时间，然后重新将其插入定时器队列。如果期限在过去结束，则 Xen 永远不会保留 __do_softirq。受影响的 PCPU 会一直保留在无限循环中，直至 Xen 由监视程序（如果启用）终止为止。这是安全问题，XSA-20/CVE-2012-4535。(CVE-2012-4535)

- 修正 HVM 客户机变更集 24947:b198ada9689d 的 RTC 时间偏移更新错误

- 始终在关闭 VM 时释放 vm 运行锁定 安装此修补程序之前，重新启动 xend 后，关闭时不释放 VM 运行锁定，所以 VM 可能永不再次启动。与 Junjie 交谈之后，我们建议始终在 VM 关闭时释放锁定。因此即使重新启动 xend，这里应该也不会保留任何过时的锁定。

检测

OracleVM 3.1：xen (OVMSA-2012-0051)

medium Nessus 插件 ID 79489

未找到变更日志