Racy interactions between dirty vram tracking and paging log dirty hypercalls

ISSUE DESCRIPTION

Activation of log dirty mode done by XEN_DMOP_track_dirty_vram (was named HVMOP_track_dirty_vram before Xen 4.9) is racy with ongoing log dirty hypercalls. A suitably timed call to XEN_DMOP_track_dirty_vram can enable log dirty while another CPU is still in the process of tearing down the structures related to a previously enabled log dirty mode (XEN_DOMCTL_SHADOW_OP_OFF). This is due to lack of mutually exclusive locking between both operations and can lead to entries being added in already freed slots, resulting in a memory leak.

IMPACT

An attacker can cause Xen to leak memory, eventually leading to a Denial of Service (DoS) affecting the entire host.

VULNERABLE SYSTEMS

All Xen versions from at least 4.0 onwards are vulnerable.
Only x86 systems are vulnerable. Arm systems are not vulnerable.
Only domains controlling an x86 HVM guest using Hardware Assisted Paging (HAP) can leverage the vulnerability. On common deployments this is limited to domains that run device models on behalf of guests.