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 :(
>
> 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@xxxxxxxxxx>
> ---
> drivers/usb/gadget/function/uvc_video.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
What commit id does this fix?
>
> 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?
thanks,
greg k-h
