CVE-2022-50257

*** Pendiente de traducción *** 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-&gt;map_ops[i].status == GNTST_okay) {<br /> map-&gt;unmap_ops[i].handle = map-&gt;map_ops[i].handle;<br /> if (!use_ptemod)<br /> alloced++;<br /> }<br /> if (use_ptemod) {<br /> if (map-&gt;kmap_ops[i].status == GNTST_okay) {<br /> if (map-&gt;map_ops[i].status == GNTST_okay)<br /> alloced++;<br /> map-&gt;kunmap_ops[i].handle = map-&gt;kmap_ops[i].handle;<br /> }<br /> }<br /> }<br /> ...<br /> atomic_add(alloced, &amp;map-&gt;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-&gt;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(&amp;map-&gt;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-&gt;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-&gt;count" (i.e., a value that can be greater than map-&gt;live_grants)<br /> from map-&gt;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&amp;#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.