Memory Protection Extensions (MPX) and Protection Key (PKU) are features in newer processors, whose state is intended to be per-thread and context switched along with all other XSAVE state.
Xen’s vCPU context switch code would save and restore the state only if the guest had set the relevant XSTATE enable bits. However, surprisingly, the use of these features is not dependent (PKU) or may not be dependent (MPX) on having the relevant XSTATE bits enabled.
VMs which use MPX or PKU, and context switch the state manually rather than via XSAVE, will have the state leak between vCPUs (possibly, between vCPUs in different guests). This in turn corrupts state in the destination vCPU, and hence may lead to weakened protections
Experimentally, MPX appears not to make any interaction with BND* state if BNDCFGS.EN is set but XCR0.BND{CSR,REGS} are clear. However, the SDM is not clear in this case; therefore MPX is included in this advisory as a precaution.
There is an information leak, of control information mentioning pointers into guest address space; this may weaken address space randomisation and make other attacks easier.
When an innocent guest acquires leaked state, it will run with incorrect protection state. This could weaken the protection intended by the MPX or PKU features, making other attacks easier which would otherwise be excluded; and the incorrect state could also cause a denial of service by preventing legitimate accesses.
Guests which use XSAVE for context switching PKU and MPX state are not vulnerable to inbound corruption caused by another malicious domain.
With respect to PKU, the remaining outbound information leak is of no conceivable consequence. And, experimentally, MPX does not appear to have a real vulnerability, even though the CPU documentation is not clear.
Therefore we think that these guests (those which use XSAVE) are not vulnerable.
Linux uses XSAVE, so is therefore not vulnerable.