Race condition in HVMOP_track_dirty_vram
The routine controlling the setup of dirty video RAM tracking latches the value of a pointer before taking the respective guarding lock, thus making it possible for a stale pointer to be used by the time the lock got acquired and the pointer gets dereferenced.
The hypercall providing access to the affected function is available to the domain controlling HVM guests.
race condition (read w/o lock)
x86/shadow: fix race condition sampling the dirty vram state
d->arch.hvm_domain.dirty_vram must be read with the domain’s paging lock held.
If not, two concurrent hypercalls could both end up attempting to free dirty_vram (the second of which will free a wild pointer), or both end up allocating a new dirty_vram structure (the first of which will be leaked).
d->arch.hvm_domain.dirty_vram 必须在d的lock被hold之后再被读取，否则会有race (by two concurrent hypercalls)，造成double free或memory leak.
Malicious or buggy stub domain kernels or tool stacks otherwise living outside of Domain0 can mount a denial of service attack which, if successful, can affect the whole system.