|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH 3/3] improve XENMEM_add_to_physmap_batch address checking
As a follow-up to XSA-212 we should have addressed a similar issue here:
The handles being advanced at the top of xenmem_add_to_physmap_batch()
means we allow hypervisor space accesses (in particular, for "errs",
writes) with suitably crafted input arguments. This isn't a security
issue in this case because of the limited width of struct
xen_add_to_physmap_batch's size field: It being 16-bits wide, only the
r/o M2P area can be accessed. Still we can and should do better.
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -823,6 +823,11 @@ static int xenmem_add_to_physmap_batch(s
guest_handle_add_offset(xatpb->errs, start);
xatpb->size -= start;
+ if ( !guest_handle_okay(xatpb->idxs, xatpb->size) ||
+ !guest_handle_okay(xatpb->gpfns, xatpb->size) ||
+ !guest_handle_okay(xatpb->errs, xatpb->size) )
+ return -EFAULT;
+
while ( xatpb->size > done )
{
xen_ulong_t idx;
@@ -1141,10 +1146,7 @@ long do_memory_op(unsigned long cmd, XEN
if ( start_extent != (typeof(xatpb.size))start_extent )
return -EDOM;
- if ( copy_from_guest(&xatpb, arg, 1) ||
- !guest_handle_okay(xatpb.idxs, xatpb.size) ||
- !guest_handle_okay(xatpb.gpfns, xatpb.size) ||
- !guest_handle_okay(xatpb.errs, xatpb.size) )
+ if ( copy_from_guest(&xatpb, arg, 1) )
return -EFAULT;
/* This mapspace is unsupported for this hypercall. */
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |