x86 shadow pagetables: address width overflow

ISSUE DESCRIPTION

In the x86 shadow pagetable code, the guest frame number of a superpage mapping is stored in a 32-bit field. If a shadowed guest can cause a superpage mapping of a guest-physical address at or above 2^44 to be shadowed, the top bits of the address will be lost, causing an assertion failure or NULL dereference later on, in code that removes the shadow.

IMPACT

A HVM guest using shadow pagetables can cause the host to crash.
A PV guest using shadow pagetables (i.e. being migrated) with PV superpages enabled (which is not the default) can crash the host, or corrupt hypervisor memory, and so a privilege escalation cannot be ruled out.

VULNERABLE SYSTEMS

Xen versions from 3.4 onwards are affected.
Only x86 variants of Xen are susceptible. ARM variants are not affected.
HVM guests using shadow mode paging can expose this vulnerability. HVM guests using Hardware Assisted Paging (HAP) are unaffected.
Systems running PV guests with PV superpages enabled are vulnerable if those guests undergo live migration. PV superpages are disabled by default, so systems are not vulnerable in this way unless “allowsuperpage” is on the Xen command line.
To discover whether your HVM guests are using HAP, or shadow page tables: request debug key q' (from the Xen console, or with xl debug-keys q’). This will print (to the console, and visible in xl dmesg'), debug information for every domain, containing something like this: (XEN) General information for domain 2: (XEN) refcnt=1 dying=2 pause_count=2 (XEN) nr_pages=2 xenheap_pages=0 shared_pages=0 paged_pages=0 dirty_cpus={} max_pages=262400 (XEN) handle=ef58ef1a-784d-4e59-8079-42bdee87f219 vm_assist=00000000 (XEN) paging assistance: hap refcounts translate external ^^^ The presence of hap’ here indicates that the host is not vulnerable to this domain. For an HVM domain the presence of `shadow’ indicates that the domain can exploit the vulnerability.