CVE-2022-50257
Publication date:
15/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
xen/gntdev: Prevent leaking grants<br />
<br />
Prior to this commit, if a grant mapping operation failed partially,<br />
some of the entries in the map_ops array would be invalid, whereas all<br />
of the entries in the kmap_ops array would be valid. This in turn would<br />
cause the following logic in gntdev_map_grant_pages to become invalid:<br />
<br />
for (i = 0; i count; i++) {<br />
if (map->map_ops[i].status == GNTST_okay) {<br />
map->unmap_ops[i].handle = map->map_ops[i].handle;<br />
if (!use_ptemod)<br />
alloced++;<br />
}<br />
if (use_ptemod) {<br />
if (map->kmap_ops[i].status == GNTST_okay) {<br />
if (map->map_ops[i].status == GNTST_okay)<br />
alloced++;<br />
map->kunmap_ops[i].handle = map->kmap_ops[i].handle;<br />
}<br />
}<br />
}<br />
...<br />
atomic_add(alloced, &map->live_grants);<br />
<br />
Assume that use_ptemod is true (i.e., the domain mapping the granted<br />
pages is a paravirtualized domain). In the code excerpt above, note that<br />
the "alloced" variable is only incremented when both kmap_ops[i].status<br />
and map_ops[i].status are set to GNTST_okay (i.e., both mapping<br />
operations are successful). However, as also noted above, there are<br />
cases where a grant mapping operation fails partially, breaking the<br />
assumption of the code excerpt above.<br />
<br />
The aforementioned causes map->live_grants to be incorrectly set. In<br />
some cases, all of the map_ops mappings fail, but all of the kmap_ops<br />
mappings succeed, meaning that live_grants may remain zero. This in turn<br />
makes it impossible to unmap the successfully grant-mapped pages pointed<br />
to by kmap_ops, because unmap_grant_pages has the following snippet of<br />
code at its beginning:<br />
<br />
if (atomic_read(&map->live_grants) == 0)<br />
return; /* Nothing to do */<br />
<br />
In other cases where only some of the map_ops mappings fail but all<br />
kmap_ops mappings succeed, live_grants is made positive, but when the<br />
user requests unmapping the grant-mapped pages, __unmap_grant_pages_done<br />
will then make map->live_grants negative, because the latter function<br />
does not check if all of the pages that were requested to be unmapped<br />
were actually unmapped, and the same function unconditionally subtracts<br />
"data->count" (i.e., a value that can be greater than map->live_grants)<br />
from map->live_grants. The side effects of a negative live_grants value<br />
have not been studied.<br />
<br />
The net effect of all of this is that grant references are leaked in one<br />
of the above conditions. In Qubes OS v4.1 (which uses Xen&#39;s grant<br />
mechanism extensively for X11 GUI isolation), this issue manifests<br />
itself with warning messages like the following to be printed out by the<br />
Linux kernel in the VM that had granted pages (that contain X11 GUI<br />
window data) to dom0: "g.e. 0x1234 still pending", especially after the<br />
user rapidly resizes GUI VM windows (causing some grant-mapping<br />
operations to partially or completely fail, due to the fact that the VM<br />
unshares some of the pages as part of the window resizing, making the<br />
pages impossible to grant-map from dom0).<br />
<br />
The fix for this issue involves counting all successful map_ops and<br />
kmap_ops mappings separately, and then adding the sum to live_grants.<br />
During unmapping, only the number of successfully unmapped grants is<br />
subtracted from live_grants. The code is also modified to check for<br />
negative live_grants values after the subtraction and warn the user.
Severity CVSS v4.0: Pending analysis
Last modification:
15/09/2025
