Re: [PATCH v2] usb: gadget: f_uac1_legacy: remove broken string configfs attributes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing bounds checking on integer configfs attributes leads to ZERO_SIZE_PTR dereference and kernel crash.
- [High] Permanent memory and request leak when the USB host changes alternate settings.
--

--- Patch [1]: [PATCH v2] usb: gadget: f_uac1_legacy: remove broken string configfs attributes ---
commit 4b8c64c0b84575a689f911f2adeef96bb30cecea
Author: Xu Yang <xu.yang_2@nxp.com>

usb: gadget: f_uac1_legacy: remove broken string configfs attributes

The UAC1_STR_ATTRIBUTE macro defines configfs show/store handlers for
the fn_play, fn_cap, and fn_cntl string options. The store function
contains an inverted null check on the kstrndup() return value. This
patch removes the UAC1_STR_ATTRIBUTE macro and the three attributes it
generated, as they have been broken and unused for many years.

Link: https://lore.kernel.org/linux-usb/20260625113154.1954813-1-xu.yang_2@oss.nxp.com/

> diff --git a/drivers/usb/gadget/function/f_uac1_legacy.c b/drivers/usb/gadget/function/f_uac1_legacy.c
> index 5d201a2e30e7f..3f52099a4fdd5 100644
> --- a/drivers/usb/gadget/function/f_uac1_legacy.c
> +++ b/drivers/usb/gadget/function/f_uac1_legacy.c
> @@ -888,60 +888,10 @@ UAC1_INT_ATTRIBUTE(req_buf_size);
>  UAC1_INT_ATTRIBUTE(req_count);
>  UAC1_INT_ATTRIBUTE(audio_buf_size);

[Severity: High]
This isn't a bug introduced by this patch, but does this lack of bounds
checking allow audio_buf_size to be set to 0?

If a user with configfs access sets audio_buf_size to 0, it appears
f_audio_buffer_alloc() will call kzalloc(0) which returns ZERO_SIZE_PTR:

drivers/usb/gadget/function/f_uac1_legacy.c:f_audio_buffer_alloc() {
	...
	copy_buf->buf = kzalloc(buf_size, GFP_ATOMIC);
	if (!copy_buf->buf) {
	...
}

This bypasses the NULL check. Later, when an audio out packet is received,
f_audio_out_ep_complete() attempts to memcpy the incoming data:

drivers/usb/gadget/function/f_uac1_legacy.c:f_audio_out_ep_complete() {
	...
	memcpy(copy_buf->buf + copy_buf->actual, req->buf, req->actual);
	...
}

Can this copy into the ZERO_SIZE_PTR address cause an immediate kernel panic?

> -#define UAC1_STR_ATTRIBUTE(name)					\
> -static ssize_t f_uac1_opts_##name##_show(struct config_item *item,	\

[ ... ]

> @@ -956,12 +906,6 @@ static void f_audio_free_inst(struct usb_function_instance *f)
>  	struct f_uac1_legacy_opts *opts;
>  
>  	opts = container_of(f, struct f_uac1_legacy_opts, func_inst);
> -	if (opts->fn_play_alloc)
> -		kfree(opts->fn_play);
> -	if (opts->fn_cap_alloc)
> -		kfree(opts->fn_cap);
> -	if (opts->fn_cntl_alloc)
> -		kfree(opts->fn_cntl);
>  	kfree(opts);
>  }

[Severity: High]
This is a pre-existing issue, but does f_audio_disable() leak memory and USB
requests when the host changes alternate settings?

When the USB host selects alternate setting 1, f_audio_set_alt() allocates
requests and buffers:

drivers/usb/gadget/function/f_uac1_legacy.c:f_audio_set_alt() {
	...
	req = usb_ep_alloc_request(out_ep, GFP_ATOMIC);
	if (req) {
		req->buf = kzalloc(req_buf_size, GFP_ATOMIC);
	...
}

However, the disable callback appears to be empty and fails to free these
resources:

drivers/usb/gadget/function/f_uac1_legacy.c:f_audio_disable() {
	return;
}

Could an untrusted USB host trigger this repeatedly by changing the alternate
setting back and forth, exhausting device memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713060845.3759673-1-xu.yang_2@oss.nxp.com?part=1