Hypervisor heap contents leaked to guests

While memory pages recovered from dying guests are being cleaned to avoid leaking sensitive information to other guests, memory pages that were in use by the hypervisor and are eligible to be allocated to guests weren’t being properly cleaned. Such exposure of information would happen through memory pages freshly allocated to or by the guest.

Normally the leaked data is administrative information of limited value to an attacker. However, scenarios exist where guest CPU register state and hypercall arguments might be leaked.

dying guest内存被clean了,但是hypervisor正在使用的相关page not properly cleaned, 会被allocate to other guest.

improper error handling (use after free)



page-alloc: scrub pages used by hypervisor upon freeing

… unless they’re part of a fully separate pool (and hence can’t ever be used for guest allocations).

--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1409,7 +1409,10 @@ void free_xenheap_pages(void *v, unsigne
     pg = virt_to_page(v);
     for ( i = 0; i < (1u << order); i++ )
+    {
+        scrub_one_page(&pg[i]);
         pg[i].count_info &= ~PGC_xen_heap;
+    }
     free_heap_pages(pg, order);
@@ -1579,6 +1582,8 @@ void free_domheap_pages(struct page_info
         /* Freeing anonymous domain-heap pages. */
+        for ( i = 0; i < (1 << order); i++ )
+            scrub_one_page(&pg[i]);
         free_heap_pages(pg, order);
         drop_dom_ref = 0;

clean corresponding pages.


A malicious guest might be able to read data relating to other guests or the hypervisor itself.

Data at rest in guest memory or storage (filesystems) is not affected. However, it is possible for an attacker to obtain modest amounts of in-flight and in-use data, which might contain passwords or cryptographic keys.

information leak