遠端 OracleVM 系統缺少可解決重要安全性更新的必要修補程式：

- libxc：builder：限制核心/ramdisk 的大小上限。
 若允許使用者提供任意大小的核心，尤其在解壓縮期間，可消耗 dom0 記憶體而導致 builder 處理程序中的虛擬位址空間耗盡，或是 toolstack 和不相關的處理程序皆發生配置失敗/OOM 終止。在 pvgrub 的虛設常式網域中進行構建時會停用這些檢查，因為其會使用來賓自己的記憶體且為隔離狀態。以 gzip 壓縮的核心和 ramdisk 的解壓縮作業，自 14954:58205257517d (Xen 3.1.0 及 更新版本) 起皆為安全狀態。這是 XSA-25 / CVE-2012-4544。亦明確檢查多種解壓縮常式中是否有緩衝區溢位問題。這些問題已因程式碼的其他內容而排除，但是會作為額外安全措施進行檢查。

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

- compat/gnttab：防止在相容程式碼 c/s 20281:95ea2052b41b 中進入無限迴圈，該程式碼納入了授權表版本 2 且 hypercall 引入一個弱點，可讓相容的 hypercall 處置程式進入無限迴圈。
 若啟用看門狗，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 表格。在此情況下，隨後由來賓叫用的記憶體作業可能會導致錯誤和宣告，從而終止 Xen。此問題已修正，現在如果 p2m 未成功更新，則只會更新 m2p 表格。這是安全性問題，XSA-22 / CVE-2012-4537。
 (CVE-2012-4537)

- x86/physdev：對來賓的 pirq 參數進行範圍檢查，否則 Xen 會超出結構 domain.arch.pirq_emuirq 陣列的結尾讀取，這通常會導致嚴重頁面錯誤。此弱點是由 c/s 23241:d21100f1d00e 引入，其為 domain_pirq_to_emuirq 新增了一個呼叫，該呼叫會在進行範圍檢查前使用來賓提供的 pirq 值，而該弱點已由 c/s 23573:584c2e5e03d9 修正，將 domain_pirq_to_emuirq 巨集的行為變更為使用基數樹狀結構而非平面陣列。這是 XSA-21 / CVE-2012-4536。
 (CVE-2012-4536)

- VCPU/計時器：防止計算中出現溢位，進而導致 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 Plugin ID 79489

找不到變更記錄