lock order inversion in transitive grant copy handling

ISSUE DESCRIPTION

As part of XSA-226 a missing cleanup call was inserted on an error handling path. While doing so, locking requirements were not paid attention to. As a result two cooperating guests granting each other transitive grants can cause locks to be acquired nested within one another, but in respectively opposite order. With suitable timing between the involved grant copy operations this may result in the locking up of a CPU.

IMPACT

Malicious or buggy guest kernels may be able to mount a Denial of Service (DoS) attack affecting the entire system.

VULNERABLE SYSTEMS

Xen versions 4.0 and newer are vulnerable. Xen versions 3.4 and older are not vulnerable.
Only guests with access to transitive grants can exploit the vulnerability. In particular, this means that:

• ARM systems which have taken the XSA-268 fix are not vulnerable, as Grant Table v2 was disabled for other security reasons.
• All systems with the XSA-226 fixes, and booted with gnttab=max-ver:1 or gnttab=no-transitive are not vulnerable.
• From Xen 4.16, the maximum grant table version can be controlled on a per-domain basis. For the xl toolstack, the vulnerability does not manifest if either:

1. Every guest has max_grant_version=1 in their configuration file, or
2. The global xl.conf has max_grant_version=1, and no guests have the default overridden by selecting max_grant_version=2.
   Only multiple cooperating guests can exploit the vulnerability.