CVE-2026-68372: usb: core: port: Deattach Type-C connector on component unbind

In the Linux kernel, the following vulnerability has been resolved:

usb: core: port: Deattach Type-C connector on component unbind

connectorunbind() is the mirror of connectorbind(), but it is missing the symmetric call to typecdeattach() that connectorbind() makes via:

if (portdev->child) typecattach(portdev->connector, &portdev->child->dev);

When a Thunderbolt dock is unplugged, two teardown paths race:

1. The component framework calls connectorunbind() first, which sets portdev->connector = NULL without calling typecdeattach(). This leaves port->usb2dev/port->usb3dev in struct typecport pointing at the USB device that is about to be freed.

2. usbdisconnect() then calls typecdeattach(portdev->connector, ...), but portdev->connector is already NULL, so the call is a no-op and port->usb2dev is never cleared.

3. Concurrently, UCSI detects a PD partner-disconnect event and calls typecunregisterpartner(), which reads port->usb2dev (now a dangling pointer to freed memory) and passes it to typecpartnerunlinkdevice() -> sysfsremovelink() -> devname() on the freed device, corrupting the typec/UCSI partner state.

This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising ("PCIe link lost"), and the subsequent igcreset attempt hits igcrd32 on an already-detached device:

igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igcmain.c:7005 igcrd32+0xa4/0xc0 [igc] Call Trace: igcdisablepciemaster+0x16/0xa0 [igc] igcresethwbase+0x14/0x170 [igc] igcreset+0x63/0x110 [igc] igcioslotreset+0x9e/0xd0 [igc] reportslotreset+0x5d/0xc0 pciedorecovery+0x209/0x400 aerisroneerrortype+0x235/0x430 aerisr+0x4e/0x80 irqthread+0xf4/0x1f0

4. UCSI later handles the PD partner-disconnect and calls typecunregisterpartner(), which still sees the stale port->usb2dev and tries to remove its sysfs link a second time:

kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfsremovebynamens+0xe9/0xf0 Workqueue: events ucsihandleconnectorchange [typecucsi] Call Trace: sysfsremovelink+0x19/0x50 typecunregisterpartner+0x6e/0x120 [typec] ucsiunregisterpartner+0x107/0x150 [typecucsi] ucsihandleconnectorchange+0x3ec/0x490 [typecucsi] processonework+0x18e/0x3e0 workerthread+0x2e3/0x420 kthread+0x10a/0x230 retfromfork+0x121/0x140 retfromforkasm+0x1a/0x30

With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free.

Fix the asymmetry: call typecdeattach() before clearing portdev->connector, matching what connectorbind() does on the bind side. typecpartnerdeattach() is already protected by port->partnerlinklock, so it serialises safely with the concurrent typecunregisterpartner() path.