All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: Krzysztof Opasiak <k.opasiak@samsung.com>,
	Linux USB <linux-usb@vger.kernel.org>
Cc: stable@vger.kernel.org
Subject: Re: [PATCH 2/2] usb: gadget: function: f_fs: pass companion descriptor along
Date: Fri, 10 Mar 2017 13:43:08 +0200	[thread overview]
Message-ID: <87lgsdxsqb.fsf@linux.intel.com> (raw)
In-Reply-To: <8e061284-c5e1-2e09-1ca4-184164de1314@samsung.com>

[-- Attachment #1: Type: text/plain, Size: 2870 bytes --]


Hi,

Krzysztof Opasiak <k.opasiak@samsung.com> writes:
>> Krzysztof Opasiak <k.opasiak@samsung.com> writes:
>>> On 01/31/2017 02:08 PM, Felipe Balbi wrote:
>>>> If we're dealing with SuperSpeed endpoints, we need
>>>> to make sure to pass along the companion descriptor
>>>> and initialize fields needed by the Gadget
>>>> API. Eventually, f_fs.c should be converted to use
>>>> config_ep_by_speed() like all other functions,
>>>> though.
>>>>
>>>> Cc: <stable@vger.kernel.org>
>>>> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>>>> ---
>>>>
>>>> Will be sent in a pull request during v4.11-rc
>>>>
>>>>  drivers/usb/gadget/function/f_fs.c | 15 +++++++++++++--
>>>>  1 file changed, 13 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
>>>> index 87fccf611b69..86aba2ebb3ef 100644
>>>> --- a/drivers/usb/gadget/function/f_fs.c
>>>> +++ b/drivers/usb/gadget/function/f_fs.c
>>>> @@ -1833,11 +1833,14 @@ static int ffs_func_eps_enable(struct ffs_function *func)
>>>>  	spin_lock_irqsave(&func->ffs->eps_lock, flags);
>>>>  	while(count--) {
>>>>  		struct usb_endpoint_descriptor *ds;
>>>> +		struct usb_ss_ep_comp_descriptor *comp_desc = NULL;
>>>> +		int needs_comp_desc = false;
>>>>  		int desc_idx;
>>>>  
>>>> -		if (ffs->gadget->speed == USB_SPEED_SUPER)
>>>> +		if (ffs->gadget->speed == USB_SPEED_SUPER) {
>>>>  			desc_idx = 2;
>>>> -		else if (ffs->gadget->speed == USB_SPEED_HIGH)
>>>> +			needs_comp_desc = true;
>>>> +		} else if (ffs->gadget->speed == USB_SPEED_HIGH)
>>>>  			desc_idx = 1;
>>>>  		else
>>>>  			desc_idx = 0;
>>>> @@ -1854,6 +1857,14 @@ static int ffs_func_eps_enable(struct ffs_function *func)
>>>>  
>>>>  		ep->ep->driver_data = ep;
>>>>  		ep->ep->desc = ds;
>>>> +
>>>> +		comp_desc = (struct usb_ss_ep_comp_descriptor *)(ds +
>>>> +				USB_DT_ENDPOINT_SIZE);
>>>> +		ep->ep->maxburst = comp_desc->bMaxBurst + 1;
>>>> +
>>>> +		if (needs_comp_desc)
>>>> +			ep->ep->comp_desc = comp_desc;
>>>> +
>>>
>>> Please correct me if I'm wrong but wouldn't we read rubbish here if user
>>> provided us SS ep descriptor without companion descriptor?
>> 
>> companion desc is required for SS endpoints, it's also required that
>> they follow EP desc. If user doesn't write it, don't they deserve the
>> errors they'll have?
>> 
>
> But do we deserve to access potentially unallocated memory inside kernel
> each time when some malicious application requests this?;)
>
> In my humble opinion user should get -EINVAL or sth like this from
> write(desc, sizeof(desc)) instead of some random data in companion
> descriptor.

We are *already* getting random data in companion descriptor :-) But I
agree that -EINVAL would be really nice. Can you cook up a patch for
that?

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

      reply	other threads:[~2017-03-10 11:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-31 13:08 [PATCH 1/2] usb: dwc3: gadget: make Set Endpoint Configuration macros safe Felipe Balbi
2017-01-31 13:08 ` [PATCH 2/2] usb: gadget: function: f_fs: pass companion descriptor along Felipe Balbi
2017-01-31 15:20   ` Krzysztof Opasiak
2017-01-31 15:56     ` Felipe Balbi
2017-01-31 16:40       ` Krzysztof Opasiak
2017-03-10 11:43         ` Felipe Balbi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lgsdxsqb.fsf@linux.intel.com \
    --to=felipe.balbi@linux.intel.com \
    --cc=k.opasiak@samsung.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.