CVE-2026-68372 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
usb: core: port: Deattach Type-C connector on component unbind
connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() 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 connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed.
2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->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 typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> 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 igc_reset attempt hits igc_rd32 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 typec_unregister_partner(), 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 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi]
Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec]
ucsi_unregister_partner+0x107/0x150 [typec_ucsi]
ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi]
process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_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 typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability described relates to a critical inconsistency in the Linux kernel's USB subsystem handling of Thunderbolt dock connections, specifically within the Type-C connector management framework. This flaw manifests during the unbinding process of USB components when a Thunderbolt dock is unplugged, creating a race condition that leads to memory corruption and system instability. The issue stems from an asymmetric implementation between the binding and unbinding functions, where connector_bind() properly calls typec_attach() but connector_unbind() fails to invoke the corresponding typec_deattach() function, resulting in dangling references to freed USB device structures.
The operational impact of this vulnerability is severe, particularly on hardware utilizing Thunderbolt docks with I225/igc NICs. When a dock is unplugged, two concurrent teardown paths execute simultaneously, causing memory corruption that manifests as PCIe link loss errors and subsequent driver failures. The system attempts to access freed memory structures through UCSI (USB Type-C and Power Delivery Interface) when handling PD partner-disconnect events, leading to kernel warnings and potential use-after-free conditions. This results in the failure of network interface enumeration and can cause complete system instability during hot-plug operations.
The technical root cause lies in the improper synchronization between component framework cleanup and Type-C subsystem management. During the unbind operation, port_dev->connector is set to NULL without calling typec_deattach(), leaving stale pointers in struct typec_port that reference already-freed USB devices. This creates a scenario where usb_disconnect() cannot properly clean up the device references due to the NULL connector pointer, while UCSI concurrently attempts to access these dangling pointers during partner unregister operations. The race condition is further exacerbated by the fact that typec_partner_deattach() is protected by port->partner_link_lock but the sequence of operations fails to maintain proper ordering.
This vulnerability aligns with CWE-415 Double Free and CWE-416 Use After Free categories, as it involves accessing freed memory structures and improper resource management during device teardown. The flaw also demonstrates characteristics consistent with ATT&CK technique T1059.003 Command and Scripting Interpreter: Windows Command Shell, where improper cleanup of system resources creates exploitable conditions. The fix requires implementing symmetric behavior between the bind and unbind functions by ensuring typec_deattach() is called before clearing port_dev->connector, thereby maintaining consistency with how connector_bind() operates on the binding side.
The mitigation strategy involves modifying the connector_unbind() function to call typec_deattach() prior to setting port_dev->connector = NULL, ensuring that all Type-C subsystem references are properly cleared before the underlying USB device structures are freed. This approach maintains proper synchronization between concurrent paths and prevents memory corruption during Thunderbolt dock hot-plug operations. The solution leverages existing locking mechanisms within the Type-C subsystem to ensure safe execution of concurrent cleanup operations while maintaining system stability during normal hardware connection management scenarios.