Re: [PATCH] usb: gadget: f_uac1_legacy: cancel playback_work before freeing audio

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] usb: gadget: f_uac1_legacy: f_audio_free() leaks play_queue and copy_buf buffers
--

commit 7b0893434cf97360fc2c156524033f06ad05654d
Author: Tristan Madani <tristan@talencesecurity.com>

usb: gadget: f_uac1_legacy: cancel playback_work before freeing audio

This commit calls cancel_work_sync(&audio->playback_work) in f_audio_free()
before cleaning up the audio card and freeing the f_audio structure so that
a pending or running playback_work does not access freed memory.

> diff --git a/drivers/usb/gadget/function/f_uac1_legacy.c b/drivers/usb/gadget/function/f_uac1_legacy.c
> index 7c8d60c7e87d1..a9807697265c5 100644
> --- a/drivers/usb/gadget/function/f_uac1_legacy.c
> +++ b/drivers/usb/gadget/function/f_uac1_legacy.c
> @@ -943,6 +943,7 @@ static void f_audio_free(struct usb_function *f)
>  	struct f_audio *audio = func_to_audio(f);
>  	struct f_uac1_legacy_opts *opts;
>  
> +	cancel_work_sync(&audio->playback_work);
>  	gaudio_cleanup(&audio->card);
>  	opts = container_of(f->fi, struct f_uac1_legacy_opts, func_inst);
>  	kfree(audio);

[Severity: Medium]
Does cancelling playback_work here without draining audio->play_queue or
freeing audio->copy_buf leak struct f_audio_buf buffers?

During streaming, f_audio_out_ep_complete() appends full copy_buf buffers to
audio->play_queue and schedules audio->playback_work:

	if (audio_buf_size - copy_buf->actual < req->actual) {
		spin_lock_irq(&audio->lock);
		list_add_tail(&copy_buf->list, &audio->play_queue);
		spin_unlock_irq(&audio->lock);
		schedule_work(&audio->playback_work);
		copy_buf = f_audio_buffer_alloc(audio_buf_size);

f_audio_playback_work() is the only consumer that removes entries from
audio->play_queue and frees them with f_audio_buffer_free(), and it only
processes one entry per invocation:

	play_buf = list_first_entry(&audio->play_queue,
			struct f_audio_buf, list);
	list_del(&play_buf->list);
	spin_unlock_irq(&audio->lock);

	u_audio_playback(&audio->card, play_buf->buf, play_buf->actual);
	f_audio_buffer_free(play_buf);

When cancel_work_sync(&audio->playback_work) cancels a pending work item in
f_audio_free() (or when multiple buffers are queued on audio->play_queue, or
audio->copy_buf is still allocated), those f_audio_buf structures and their
backing data buffers are never freed before kfree(audio).

Should f_audio_free() drain and free any remaining entries on
audio->play_queue as well as audio->copy_buf after cancelling
audio->playback_work?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261104000239.2798131-1-tristmd@gmail.com?part=1