Advisory: XSA-286

An internal implementaion detail of Xen (the use of linear pagetables) resulted in incorrect pagetable manipulation when intermixing update_va_mapping() and mmu_update() hypercalls. Construct a scenario to spot this occurring.

Create two L2=>L1 partial pagetable hierarchies, with no complete mappings. Architecturally, this means we don't need a TLB flush when modifying them.

Starting with L3 pointing at the first L2=>L1 hierarchy, perform a multicall which intermixes an update_va_mapping() (to force the creation of a TLB mapping in Xen's linear pagetables), an mmu_update() (to swap to the second L2=>L1 hierarchy), and a second update_va_mapping() to insert a brand new L1e.

If Xen retains stale linear pt mappings, the first L2=>L1 hierarchy actually gets edited by the final update_va_mapping(). If Xen flushes correctly, the second L2=>L1 hierarchy gets edited.

As this depends on TLB mappings being retained, which means it is racy with rescheduling, interrupts or TLB flushing for ancillary reasons.

At the time of writing, the 64bit test seems reliable on an otherwise idle system, whereas the 32bit test isn't. (Something causes Xen to hit a continuation on every element of the compat multicall, and a TLB flush on re-entry to the guest is a side effect of the CR4 rewrite for SMEP/SMAP).

See also: tests/xsa-286/main.c