Xen devel - Feb 2013 - [PATCH] xen: fix domain unlocking in some xsm error paths

A couple of xsm error/access-denied code paths in hypercalls neglect to
unlock a previously locked domain. Fix by ensuring the domains are
unlocked correctly.

Signed-off-by: Matthew Daley <mattjd@gmail.com>
---
 xen/arch/x86/physdev.c   |    2 +-
 xen/common/grant_table.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index d9ed5df..3006266 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -111,7 +111,7 @@ int physdev_map_pirq(domid_t domid, int type, int *index,
int *pirq_p,
 
     ret = xsm_map_domain_pirq(XSM_TARGET, d);
     if ( ret )
-        return ret;
+        goto free_domain;
 
     /* Verify or get irq. */
     switch ( type )
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index f85adb4..5bd99b8 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2283,7 +2283,7 @@
gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
     rc = xsm_grant_setup(XSM_TARGET, current->domain, d);
     if ( rc ) {
         op.status = GNTST_permission_denied;
-        goto out1;
+        goto out2;
     }
 
     gt = d->grant_table;
-- 
1.7.10.4

>>> On 28.02.13 at 03:05, Matthew Daley <mattjd@gmail.com> wrote:
> A couple of xsm error/access-denied code paths in hypercalls neglect to
> unlock a previously locked domain. Fix by ensuring the domains are
> unlocked correctly.
> 
> Signed-off-by: Matthew Daley <mattjd@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -111,7 +111,7 @@ int physdev_map_pirq(domid_t domid, int type, int
*index, int *pirq_p,
>  
>      ret = xsm_map_domain_pirq(XSM_TARGET, d);
>      if ( ret )
> -        return ret;
> +        goto free_domain;
>  
>      /* Verify or get irq. */
>      switch ( type )
So it looks like this is a regression from Daniel''s recent XSM rework.
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2283,7 +2283,7 @@
gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
>      rc = xsm_grant_setup(XSM_TARGET, current->domain, d);
>      if ( rc ) {
>          op.status = GNTST_permission_denied;
> -        goto out1;
> +        goto out2;
>      }
>  
>      gt = d->grant_table;
Whereas this is something that is broken already in 4.2 (but not in
4.1). I''ll try to remember to pick this up for 4.2 once it got applied
and came out of staging.

Jan

On 28/02/2013 08:50, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 28.02.13 at 03:05, Matthew Daley <mattjd@gmail.com>
wrote:
>> A couple of xsm error/access-denied code paths in hypercalls neglect to
>> unlock a previously locked domain. Fix by ensuring the domains are
>> unlocked correctly.
>> 
>> Signed-off-by: Matthew Daley <mattjd@gmail.com>
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
>> --- a/xen/arch/x86/physdev.c
>> +++ b/xen/arch/x86/physdev.c
>> @@ -111,7 +111,7 @@ int physdev_map_pirq(domid_t domid, int type, int
*index,
>> int *pirq_p,
>>  
>>      ret = xsm_map_domain_pirq(XSM_TARGET, d);
>>      if ( ret )
>> -        return ret;
>> +        goto free_domain;
>>  
>>      /* Verify or get irq. */
>>      switch ( type )
> 
> So it looks like this is a regression from Daniel''s recent XSM
rework.
> 
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -2283,7 +2283,7 @@
>>
gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t)
>> uop,
>>      rc = xsm_grant_setup(XSM_TARGET, current->domain, d);
>>      if ( rc ) {
>>          op.status = GNTST_permission_denied;
>> -        goto out1;
>> +        goto out2;
>>      }
>>  
>>      gt = d->grant_table;
> 
> Whereas this is something that is broken already in 4.2 (but not in
> 4.1). I''ll try to remember to pick this up for 4.2 once it got
applied
> and came out of staging.
> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel