Missing memory barriers in read-write unlock paths

ISSUE DESCRIPTION

The read-write unlock paths don’t contain a memory barrier. On Arm, this means a processor is allowed to re-order the memory access with the preceding ones.
In other words, the unlock may be seen by another processor before all the memory accesses within the “critical” section.
As a consequence, it may be possible to have a writer executing a critical section at the same time as readers or another writer. In other words, many of the assumptions (e.g a variable cannot be modified after a check) in the critical sections are not safe anymore.
The read-write locks are used in hypercalls (such as grant-table ones), so a malicious guest could exploit the race. For instance, there is a small window where Xen can leak memory if XENMAPSPACE_grant_table is used concurrently.

IMPACT

A malicous guest may be able to leak memory, or cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded.

VULNERABLE SYSTEMS

Systems running all versions of Xen are affected.
Whether an individual Arm-based CPU is vulnerable depends on its memory re-ordering properties. Consult your CPU vendor.
x86 systems are not vulnerable.