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] [day] [month] [year] [list]
Message-ID: <20c1e825-8e90-4874-bff0-0985649d333e@google.com>
Date: Thu, 4 Jan 2024 13:56:32 -0800
From: Avichal Rakesh <arakesh@...gle.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: dan.scally@...asonboard.com, laurent.pinchart@...asonboard.com,
 etalvala@...gle.com, jchowdhary@...gle.com, linux-kernel@...r.kernel.org,
 linux-usb@...r.kernel.org
Subject: Re: [PATCH 1/2] usb: gadget: uvc: Fix use are free during STREAMOFF

Thank you for the review, Greg!

Sent out V2 with the comments addressed.

On 1/4/24 06:19, Greg KH wrote:
> On Fri, Dec 15, 2023 at 01:07:44PM -0800, Avichal Rakesh wrote:
>> There is a path that may lead to freed memory being referenced,
>> and causing kernel panics.
>>
>> The kernel panic has the following stack trace:
>>
>> Workqueue: uvcgadget uvcg_video_pump.c51fb85fece46625450f86adbf92c56c.cfi_jt
>> pstate: 60c00085 (nZCv daIf +PAN +UAO -TCO BTYPE=--)
>> pc : __list_del_entry_valid+0xc0/0xd4
>> lr : __list_del_entry_valid+0xc0/0xd4
>> Call trace:
>>   __list_del_entry_valid+0xc0/0xd4
>>   uvc_video_free_request+0x60/0x98
>>   uvcg_video_pump+0x1cc/0x204
>>   process_one_work+0x21c/0x4b8
>>   worker_thread+0x29c/0x574
>>   kthread+0x158/0x1b0
>>   ret_from_fork+0x10/0x30
>>
>> The root cause is that uvcg_video_usb_req_queue frees the uvc_request
>> if is_enabled is false and returns an error status. video_pump also
>> frees the associated request if uvcg_video_usb_req_queue returns an e
>> rror status, leading to double free and accessing garbage memory.
> 
> Odd line wrapping :(

Sigh! Fixed. Apologies.

> 
>>
>> To fix the issue, this patch removes freeing logic from
>> uvcg_video_usb_req_queue, and lets the callers to the function handle
>> queueing errors as they see fit.
>>
>> Signed-off-by: Avichal Rakesh <arakesh@...gle.com>
>> ---
>>  drivers/usb/gadget/function/uvc_video.c | 12 +++++++++---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> What commit id does this fix?

The commit that caused the bug is not in linus' branch yet. Added
the "Fixes" tag with the commit SHA from usb-next branch. Let me know
if I should be using some other SHA.

> 
> 
>>
>> diff --git a/drivers/usb/gadget/function/uvc_video.c b/drivers/usb/gadget/function/uvc_video.c
>> index 98ba524c27f5..e5db1be14ca3 100644
>> --- a/drivers/usb/gadget/function/uvc_video.c
>> +++ b/drivers/usb/gadget/function/uvc_video.c
>> @@ -277,8 +277,7 @@ static int uvcg_video_usb_req_queue(struct uvc_video *video,
>>  	struct list_head *list = NULL;
>>  
>>  	if (!video->is_enabled) {
>> -		uvc_video_free_request(req->context, video->ep);
>> -		return -ENODEV;
>> +		return -EINVAL;
> 
> Isn't this a separate change?  And does it actually matter?

It was meant to differentiate between usb_ep_queue failing 
and the video stream being disabled, but we don't really
care about that. Reverted.

Thank you!

- Avi.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ