linux-kernel - Re: [PATCH] usb: gadget: udc: Fix permanent block caused by 'deactivated' flag

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: <88731999-35e0-4717-b5d0-9ebed9baf814@rowland.harvard.edu>
Date: Fri, 14 Nov 2025 10:33:42 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: Jimmy Hu <hhhuuu@...gle.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-usb@...r.kernel.org, Kuen-Han Tsai <khtsai@...gle.com>,
	Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
	Roy Luo <royluo@...gle.com>, Robert Baldyga <r.baldyga@...sung.com>,
	Felipe Balbi <balbi@...com>, linux-kernel@...r.kernel.org,
	badhri@...gle.com
Subject: Re: [PATCH] usb: gadget: udc: Fix permanent block caused by
 'deactivated' flag

On Fri, Nov 14, 2025 at 04:08:41PM +0800, Jimmy Hu wrote:
> When setting a new USB configuration, some functions (e.g., UVC) can
> call usb_function_deactivate() to set the `gadget->deactivated` flag
> to `true`, intentionally blocking enumeration until a userspace
> daemon (e.g., UVC service) is ready.
> 
> This `deactivated=true` state becomes a permanent block if this flag
> is not cleared by usb_function_activate() (e.g., UVC service failure
> or config set while unplugged). This blocked state persists even if
> the cable is plugged/unplugged, as the vbus_event_work() handler is
> still blocked by the `gadget->deactivated` flag, preventing pullup()
> from being called.
> 
> This patch fixes this by modifying vbus_event_work() to clear the
> `gadget->deactivated` flag *before* usb_udc_connect_control_locked().
> This breaks the permanent block, so pullup() can now be called.

I do not believe this is the right approach.  It will fail in situations 
where the cable is plugged in and then unplugged before the function 
driver is ready -- the deactivated flag will be cleared while the driver 
still is not ready.

The proper fix is to make sure that the situation never arises.  In 
other words, if the ucv driver calls usb_function_deactivate() then it 
must guarantee that it will call usb_function_activate() at an 
appropriate time later.

Another approach would be for the composite driver to keep track of 
which function drivers have called usb_function_deactivate(), and have 
it automatically clear the deactivated flag once those drivers are all 
unbound.  But this wouldn't be necessary if the function drivers all 
behaved properly.

Alan Stern