Cloudanix VulnDB

CVE-2026-68372

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in how the system handles unplugging certain docks can leave internal pointers pointing at already-freed memory, which may cause network adapters on the dock to stop working until the computer is restarted.

Exploitation
Physical Access
Attacker needs
Physical Access
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in Linux kernel USB core Type-C connector unbind path leaves stale pointers in struct typec_port after concurrent teardown of Thunderbolt docks, allowing typec_unregister_partner and sysfs operations to dereference freed memory and trigger use-after-free or double-remove warnings.

Why it matters to the business

Unplugging a Thunderbolt dock on affected systems can corrupt USB/Thunderbolt state, causing subsequent dock connections to fail NIC enumeration, trigger PCIe AER resets, and produce kernel warnings that disrupt device hot-plug reliability and require reboots.

How an attack unfolds

An attacker with physical access repeatedly unplugs and replugs a Thunderbolt dock to trigger the bind/unbind race; the window leaves port->usb2_dev as a dangling pointer that UCSI later follows into sysfs removal and typec partner unlink, corrupting kernel state and potentially escalating to use-after-free on the next hot-plug cycle.

How to fix it

Apply the upstream kernel patch that calls typec_detach before clearing port_dev->connector in connector_unbind; rebuild and deploy the fixed kernel image across all affected distributions.

How to confirm the fix worked

Boot the patched kernel, repeatedly attach/detach a Thunderbolt dock while monitoring dmesg for absence of 'kernfs: can not remove' and 'igc_rd32' warnings; confirm connector_bind/unbind symmetry via code review or ftrace of typec_attach/detach calls.

Typical attack path

  1. Physically disconnect Thunderbolt dock to start concurrent teardown paths
  2. Trigger connector_unbind before usb_disconnect clears pointers
  3. Force UCSI PD partner-disconnect event while stale pointer remains
  4. Observe typec_unregister_partner dereference of freed device memory
  5. Repeat dock hot-plug to trigger PCIe link loss and igc driver failure

How to detect it

Search kernel logs for repeated 'kernfs: can not remove', 'igc: Failed to read reg', 'PCIe link lost', and 'typec_unregister_partner' stack traces around dock unplug events; correlate with typec_ucsi workqueue activity.

  • kernfs: can not remove 'typec', no directory
  • igc_rd32+0xa4/0xc0 [igc]
  • igc: Failed to read reg 0x0!
  • WARNING:.*typec_unregister_partner
  • ucsi_handle_connector_change

What your security team should do

  • Prioritize kernel update on systems with Thunderbolt/USB4 docks within the next maintenance window
  • Monitor vendor advisories for distribution-specific backports of the typec_detach fix
  • Add kernel oops and AER error logging to SIEM for early detection of related crashes

The record

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.

Affected packages

Ecosystem Package Introduced Fixed