[PATCH] xen: fix domain unlocking in some xsm error paths

[PATCH] xen: fix domain unlocking in some xsm error paths

[Matthew Daley]

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

Re: [PATCH] xen: fix domain unlocking in some xsm error paths

[Jan Beulich]

>>> 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

Re: [PATCH] xen: fix domain unlocking in some xsm error paths

[Keir Fraser]

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