linux-kernel - Re: [PATCH v8 2/4] usb: gadget: uvc: Allocate uvc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1d3777ec-ac12-4a9a-a19c-fb7d5013a0a6@google.com>
Date:   Fri, 27 Oct 2023 13:31:26 -0700
From:   Avichal Rakesh <arakesh@...gle.com>
To:     Dan Scally <dan.scally@...asonboard.com>,
        gregkh@...uxfoundation.org, laurent.pinchart@...asonboard.com
Cc:     etalvala@...gle.com, jchowdhary@...gle.com,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        m.grzeschik@...gutronix.de
Subject: Re: [PATCH v8 2/4] usb: gadget: uvc: Allocate uvc_requests one at a
 time

Thank you for the reviews, Dan!

Uploaded v9 with the comments addressed.

On 10/27/23 05:57, Dan Scally wrote:
> Hi Avichal - thanks for the patch
> 
> On 24/10/2023 19:36, Avichal Rakesh wrote:
>> Currently, the uvc gadget driver allocates all uvc_requests as one array
>> and deallocates them all when the video stream stops. This includes
>> de-allocating all the usb_requests associated with those uvc_requests.
>> This can lead to use-after-free issues if any of those de-allocated
>> usb_requests were still owned by the usb controller.
>>
>> <snip>
>>
>> diff --git a/drivers/usb/gadget/function/uvc_video.c b/drivers/usb/gadget/function/uvc_video.c
>> index c334802ac0a4..c180866c8e34 100644
>> --- a/drivers/usb/gadget/function/uvc_video.c
>> +++ b/drivers/usb/gadget/function/uvc_video.c
>> @@ -227,6 +227,24 @@ uvc_video_encode_isoc(struct usb_request *req, struct uvc_video *video,
>>    * Request handling
>>    */
>>
>> +static void
>> +uvc_video_free_request(struct uvc_request *ureq, struct usb_ep *ep)
>> +{
>> +    sg_free_table(&ureq->sgt);
>> +    if (ureq->req && ep) {
>> +        usb_ep_free_request(ep, ureq->req);
>> +        ureq->req = NULL;
>> +    }
>> +
>> +    kfree(ureq->req_buffer);
>> +    ureq->req_buffer = NULL;
>> +
>> +    if (!list_empty(&ureq->list))
> 
> 
> Is this conditional needed? You can only get here through the list_for_each_entry_safe()

Strictly speaking, we don't need this check right now. As you said, we currently
only get to this from within a list_for_each_entry_safe block. However, we end up
needing the check in the very next patch. Considering this is a function
with no real control over who might call it, it seemed reasonable to write 
this a little defensively in case of a partial revert of the patchset.

> 
>> +        list_del_init(&ureq->list);
>> +
>> +    kfree(ureq);
>> +}
>> +
>>  <snip>
>> @@ -322,6 +325,7 @@ uvc_video_free_requests(struct uvc_video *video)
>>   static int
>>   uvc_video_alloc_requests(struct uvc_video *video)
>>   {
>> +    struct uvc_request *ureq;
>>       unsigned int req_size;
>>       unsigned int i;
>>       int ret = -ENOMEM;
>> @@ -332,29 +336,34 @@ uvc_video_alloc_requests(struct uvc_video *video)
>>            * max_t(unsigned int, video->ep->maxburst, 1)
>>            * (video->ep->mult);
>>
>> -    video->ureq = kcalloc(video->uvc_num_requests, sizeof(struct uvc_request), GFP_KERNEL);
>> -    if (video->ureq == NULL)
>> -        return -ENOMEM;
>> +    INIT_LIST_HEAD(&video->ureqs);
> 
> 
> Probably unecessary here; it's done in uvc_video_free_requests() and uvcg_video_init() already

Ah, that is fair. Added a BUG_ON instead, like we do for video->req_size
so we still catch cases where the state might be inconsistent.

> 
>> +    for (i = 0; i < video->uvc_num_requests; i++) {
>> +        ureq = kzalloc(sizeof(struct uvc_request), GFP_KERNEL);
>> +        if (ureq == NULL)
>> +            goto error;
>> +
>> +        INIT_LIST_HEAD(&ureq->list);
>> +
>> +        list_add_tail(&ureq->list, &video->ureqs);
>>
>> <snip>

Regards,
Avi.