File 6126353d-gnttab-get-status-frames-array-capacit... of Package xen

Overview Repositories Revisions Requests Users Attributes Meta

File 6126353d-gnttab-get-status-frames-array-capacity.patch of Package xen (Revision 9af5df699950f41e5c0c70c8a970b8d0)

Currently displaying revision 9af5df699950f41e5c0c70c8a970b8d0 , Show latest

# Commit ec820035b875cdbedce5e73f481ce65963ede9ed
# Date 2021-08-25 14:19:09 +0200
# Author Jan Beulich <jbeulich@suse.com>
# Committer Jan Beulich <jbeulich@suse.com>
gnttab: fix array capacity check in gnttab_get_status_frames()

The number of grant frames is of no interest here; converting the passed
in op.nr_frames this way means we allow for 8 times as many GFNs to be
written as actually fit in the array. We would corrupt xlat areas of
higher vCPU-s (after having faulted many times while trying to write to
the guard pages between any two areas) for 32-bit PV guests. For HVM
guests we'd simply crash as soon as we hit the first guard page, as
accesses to the xlat area are simply memcpy() there.

This is CVE-2021-28699 / XSA-382.

Fixes: 18b1be5e324b ("gnttab: make resource limits per domain")
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3190,12 +3190,11 @@ gnttab_get_status_frames(XEN_GUEST_HANDL
         goto unlock;
     }
 
-    if ( unlikely(limit_max < grant_to_status_frames(op.nr_frames)) )
+    if ( unlikely(limit_max < op.nr_frames) )
     {
         gdprintk(XENLOG_WARNING,
-                 "grant_to_status_frames(%u) for d%d is too large (%u,%u)\n",
-                 op.nr_frames, d->domain_id,
-                 grant_to_status_frames(op.nr_frames), limit_max);
+                 "nr_status_frames for %pd is too large (%u,%u)\n",
+                 d, op.nr_frames, limit_max);
         op.status = GNTST_general_error;
         goto unlock;
     }

Places

File 6126353d-gnttab-get-status-frames-array-capacity.patch of Package xen (Revision 9af5df699950f41e5c0c70c8a970b8d0)

Places