[Xen-devel] Re: [PATCH] xen-gntdev: prevent using UNMAP_NOTIFY_CLEAR_BYTE on read-only mappings

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 02/09/2011 05:22 PM, Jeremy Fitzhardinge wrote:
> On 02/09/2011 12:33 PM, Daniel De Graaf wrote:
>> Signed-off-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
>>
>> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
>> index 4687cd5..00e4644 100644
>> --- a/drivers/xen/gntdev.c
>> +++ b/drivers/xen/gntdev.c
>> @@ -291,7 +291,7 @@ static int __unmap_grant_pages(struct grant_map *map, 
>> int offset, int pages)
>>              if (pgno >= offset && pgno < offset + pages && use_ptemod) {
>>                      void __user *tmp;
>>                      tmp = map->vma->vm_start + map->notify.addr;
>> -                    copy_to_user(tmp, &err, 1);
>> +                    WARN_ON(copy_to_user(tmp, &err, 1));
> 
> Please don't put side-effecty predicates in WARN_ON/BUG_ON.
> 
> There's no useful report we can return?
> 
>     J

This code is called when the application may be crashing or exiting, so
there is not guaranteed to be a return path to the program. The change
in the second part of this patch should prevent the copy_to_user from failing.

Placing the call inside WARN_ON is clearly a bad idea. Will resend a more sane
version of this patch with a comment explaining why we don't return.

> 
>>                      map->notify.flags &= ~UNMAP_NOTIFY_CLEAR_BYTE;
>>              } else if (pgno >= offset && pgno < offset + pages) {
>>                      uint8_t *tmp = kmap(map->pages[pgno]);
>> @@ -596,6 +596,12 @@ static long gntdev_ioctl_notify(struct gntdev_priv 
>> *priv, void __user *u)
>>      goto unlock_out;
>>  
>>   found:
>> +    if ((op.action & UNMAP_NOTIFY_CLEAR_BYTE) &&
>> +                    (op.flags & GNTMAP_readonly)) {
>> +            rc = -EINVAL;
>> +            goto unlock_out;
>> +    }
>> +
>>      map->notify.flags = op.action;
>>      map->notify.addr = op.index - (map->index << PAGE_SHIFT);
>>      map->notify.event = op.event_channel_port;
>>
> 


-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel