[PATCH] usb: gadget: Stall OS descriptor request for unsupported functions

[PATCH] usb: gadget: Stall OS descriptor request for unsupported functions

[Wesley Cheng]

From: Chandana Kishori Chiluveru <cchiluve@codeaurora.org>

Hosts which request "OS descriptors" from gadgets do so during
the enumeration phase and before the configuration is set with
SET_CONFIGURATION. Composite driver supports OS descriptor
handling in composite_setup function. This requires to pass
signature field, vendor code, compatibleID and subCompatibleID
from user space.

For USB compositions that contain functions which don't implement os
descriptors, Windows is sending vendor specific requests for os
descriptors and composite driver handling this request with invalid
data. With this invalid info host resetting the bus and never
selecting the configuration and leading enumeration issue.

Fix this by bailing out from the OS descriptor setup request
handling if the functions does not have OS descriptors compatibleID.

Signed-off-by: Chandana Kishori Chiluveru <cchiluve@codeaurora.org>
Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
---
 drivers/usb/gadget/composite.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 72a9797..473edda6 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1945,6 +1945,12 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl)
 				buf[6] = w_index;
 				/* Number of ext compat interfaces */
 				count = count_ext_compat(os_desc_cfg);
+				/*
+				 * Bailout if device does not
+				 * have ext_compat interfaces.
+				 */
+				if (count == 0)
+					break;
 				buf[8] = count;
 				count *= 24; /* 24 B/ext compat desc */
 				count += 16; /* header */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] usb: gadget: Stall OS descriptor request for unsupported functions

[Jack Pham]

Hi Wesley,

On Mon, Mar 22, 2021 at 06:50:17PM -0700, Wesley Cheng wrote:
> From: Chandana Kishori Chiluveru <cchiluve@codeaurora.org>
> 
> Hosts which request "OS descriptors" from gadgets do so during
> the enumeration phase and before the configuration is set with
> SET_CONFIGURATION. Composite driver supports OS descriptor
> handling in composite_setup function. This requires to pass
> signature field, vendor code, compatibleID and subCompatibleID
> from user space.
> 
> For USB compositions that contain functions which don't implement os
> descriptors, Windows is sending vendor specific requests for os
> descriptors and composite driver handling this request with invalid
> data. With this invalid info host resetting the bus and never
> selecting the configuration and leading enumeration issue.
> 
> Fix this by bailing out from the OS descriptor setup request
> handling if the functions does not have OS descriptors compatibleID.
> 
> Signed-off-by: Chandana Kishori Chiluveru <cchiluve@codeaurora.org>
> Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
> ---
>  drivers/usb/gadget/composite.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
> index 72a9797..473edda6 100644
> --- a/drivers/usb/gadget/composite.c
> +++ b/drivers/usb/gadget/composite.c
> @@ -1945,6 +1945,12 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl)
>  				buf[6] = w_index;
>  				/* Number of ext compat interfaces */
>  				count = count_ext_compat(os_desc_cfg);
> +				/*
> +				 * Bailout if device does not
> +				 * have ext_compat interfaces.
> +				 */
> +				if (count == 0)
> +					break;
>  				buf[8] = count;
>  				count *= 24; /* 24 B/ext compat desc */
>  				count += 16; /* header */

Do we still need this fix? IIRC we had this change in our downstream
kernel to fix the case when dynamically re-configuring ConfigFS, i.e.
changing the composition of functions wherein none of the interfaces
support OS Descriptors, so this causes count_ext_compat() to return
0 and results in the issue described in $SUBJECT.

But I think this is more of a problem of an improperly configured
ConfigFS gadget. If userspace instead removes the config from the
gadget's os_desc subdirectory that should cause cdev->os_desc_config to
be set to NULL and hence composite_setup() should never enter this
handling at all, right?

Jack
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] usb: gadget: Stall OS descriptor request for unsupported functions

[Wesley Cheng]

On 3/22/2021 11:25 PM, Jack Pham wrote:
> Hi Wesley,
> 
> On Mon, Mar 22, 2021 at 06:50:17PM -0700, Wesley Cheng wrote:
>> From: Chandana Kishori Chiluveru <cchiluve@codeaurora.org>
>>
>> Hosts which request "OS descriptors" from gadgets do so during
>> the enumeration phase and before the configuration is set with
>> SET_CONFIGURATION. Composite driver supports OS descriptor
>> handling in composite_setup function. This requires to pass
>> signature field, vendor code, compatibleID and subCompatibleID
>> from user space.
>>
>> For USB compositions that contain functions which don't implement os
>> descriptors, Windows is sending vendor specific requests for os
>> descriptors and composite driver handling this request with invalid
>> data. With this invalid info host resetting the bus and never
>> selecting the configuration and leading enumeration issue.
>>
>> Fix this by bailing out from the OS descriptor setup request
>> handling if the functions does not have OS descriptors compatibleID.
>>
>> Signed-off-by: Chandana Kishori Chiluveru <cchiluve@codeaurora.org>
>> Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
>> ---
>>  drivers/usb/gadget/composite.c | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
>> index 72a9797..473edda6 100644
>> --- a/drivers/usb/gadget/composite.c
>> +++ b/drivers/usb/gadget/composite.c
>> @@ -1945,6 +1945,12 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl)
>>  				buf[6] = w_index;
>>  				/* Number of ext compat interfaces */
>>  				count = count_ext_compat(os_desc_cfg);
>> +				/*
>> +				 * Bailout if device does not
>> +				 * have ext_compat interfaces.
>> +				 */
>> +				if (count == 0)
>> +					break;
>>  				buf[8] = count;
>>  				count *= 24; /* 24 B/ext compat desc */
>>  				count += 16; /* header */
> 
> Do we still need this fix? IIRC we had this change in our downstream
> kernel to fix the case when dynamically re-configuring ConfigFS, i.e.
> changing the composition of functions wherein none of the interfaces
> support OS Descriptors, so this causes count_ext_compat() to return
> 0 and results in the issue described in $SUBJECT.
> 
Hi Jack,

You're correct.  We can address this as well in the userspace perspective.

> But I think this is more of a problem of an improperly configured
> ConfigFS gadget. If userspace instead removes the config from the
> gadget's os_desc subdirectory that should cause cdev->os_desc_config to
> be set to NULL and hence composite_setup() should never enter this
> handling at all, right?

Sure, I'll go with fixing it in the userspace, since the support to
stall the OS desc is already present in the composite driver as you
mentioned.  Thanks for the input.

Thanks
Wesley Cheng

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project