linux-kernel - Re: [PATCH] USB: hub: Move typec deattach before children disconnections in usb

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <36a75fd9-71a4-4f53-9a35-560cd9cd5687@rowland.harvard.edu>
Date: Sun, 20 Jul 2025 21:21:25 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Marco Tormento <mtormento80@...il.com>
Cc: gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: hub: Move typec deattach before children
 disconnections in usb_disconnect()

On Sun, Jul 20, 2025 at 11:08:47PM +0200, Marco Tormento wrote:
> I tracked down the issue to the following logic:
> - power brick is plugged in
> - monitor is plugged in
> - when I unplug the monitor in usb_disconnect() hub_disconnect_children()
>   calls usb_disconnect() recursively, and this results in
>   connector_unbind() invoked on all connectors, which resets
>   port_dev->connector to NULL on the ports

I'm not a typec expert; in fact I know practically nothing about it.  
Nevertheless, this sounds strange.  The recursive usb_disconnect() calls 
should affect the connectors to the monitor's children and the monitor's 
own ports, not the connector or port on the monitor's parent hub.

> - typec_deattach() is called for each device that has a parent, which in
>   turn should fire typec_partner_deattach()
> - port_dev->connector is NULL though, so typec_partner_deattach() is not
>   called and port->usb2_dev is not set to NULL even though the hub device
>   is actually gone

But that's port_dev->connector for the port on the monitor's parent hub, 
which shouldn't have been affected.

> In order to fix the above I tried moving the code that handles typec
> deattachment from the parent before all the disconnections, this way
> typec_partner_deattach() is invoked for the partner, port->usb2_dev is
> cleared and typec_unregister_partner() is happy.

In essence, you're moving the typec_deattach() call up before the 
hub_disconnect_children() and usb_disable_device() calls.  (The 
sysfs_remove_link() calls get moved up too, but they probably don't 
matter much.)  I'm not saying this is the wrong thing to do or that it 
will cause problems, but it does seem odd.  In particular, it's not the 
reverse order of the way these things were set up when the devices were 
originally detected.

Alan Stern