CVE-2026-68372

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 (port_dev->child)
    typec_attach(port_dev->connector, &port_dev->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->usb2_dev 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() -> dev_name() 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/igc_main.c:7005
         igc_rd32+0xa4/0xc0 [igc]
Call Trace:
 igc_disable_pcie_master+0x16/0xa0 [igc]
 igc_reset_hw_base+0x14/0x170 [igc]
 igc_reset+0x63/0x110 [igc]
 igc_io_slot_reset+0x9e/0xd0 [igc]
 report_slot_reset+0x5d/0xc0
 pcie_do_recovery+0x209/0x400
 aer_isr_one_error_type+0x235/0x430
 aer_isr+0x4e/0x80
 irq_thread+0xf4/0x1f0

4. UCSI later handles the PD partner-disconnect and calls typecunregisterpartner(), which still sees the stale port->usb2_dev 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 retfromfork_asm+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 typecunregister_partner() path.