GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-3J8G-7XHM-68VV

Vulnerability from github – Published: 2026-08-10 15:33 – Updated: 2026-08-10 15:33
VLAI
Details

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
  1. 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.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-68372"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-10T13:20:30Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: core: port: Deattach Type-C connector on component unbind\n\nconnector_unbind() is the mirror of connector_bind(), but it is missing\nthe symmetric call to typec_deattach() that connector_bind() makes via:\n\n    if (port_dev-\u003echild)\n        typec_attach(port_dev-\u003econnector, \u0026port_dev-\u003echild-\u003edev);\n\nWhen a Thunderbolt dock is unplugged, two teardown paths race:\n\n1. The component framework calls connector_unbind() first, which sets\n   port_dev-\u003econnector = NULL without calling typec_deattach().  This\n   leaves port-\u003eusb2_dev/port-\u003eusb3_dev in struct typec_port pointing at\n   the USB device that is about to be freed.\n\n2. usb_disconnect() then calls typec_deattach(port_dev-\u003econnector, ...),\n   but port_dev-\u003econnector is already NULL, so the call is a no-op and\n   port-\u003eusb2_dev is never cleared.\n\n3. Concurrently, UCSI detects a PD partner-disconnect event and calls\n   typec_unregister_partner(), which reads port-\u003eusb2_dev (now a dangling\n   pointer to freed memory) and passes it to typec_partner_unlink_device()\n   -\u003e sysfs_remove_link() -\u003e dev_name() on the freed device, corrupting\n   the typec/UCSI partner state.\n\nThis corruption leaves the Thunderbolt tunnel in an inconsistent state on\nthe next dock hot-plug.  On affected hardware the dock\u0027s I225/igc NIC fails\nto enumerate: AER fires a slot reset while the igc driver is still\ninitialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits\nigc_rd32 on an already-detached device:\n\n    igc 0000:2e:00.0 eth0: PCIe link lost, device now detached\n    igc: Failed to read reg 0x0!\n    WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005\n             igc_rd32+0xa4/0xc0 [igc]\n    Call Trace:\n     igc_disable_pcie_master+0x16/0xa0 [igc]\n     igc_reset_hw_base+0x14/0x170 [igc]\n     igc_reset+0x63/0x110 [igc]\n     igc_io_slot_reset+0x9e/0xd0 [igc]\n     report_slot_reset+0x5d/0xc0\n     pcie_do_recovery+0x209/0x400\n     aer_isr_one_error_type+0x235/0x430\n     aer_isr+0x4e/0x80\n     irq_thread+0xf4/0x1f0\n\n4. UCSI later handles the PD partner-disconnect and calls\n   typec_unregister_partner(), which still sees the stale port-\u003eusb2_dev\n   and tries to remove its sysfs link a second time:\n\n   kernfs: can not remove \u0027typec\u0027, no directory\n   WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0\n   Workqueue: events ucsi_handle_connector_change [typec_ucsi]\n   Call Trace:\n    sysfs_remove_link+0x19/0x50\n    typec_unregister_partner+0x6e/0x120 [typec]\n    ucsi_unregister_partner+0x107/0x150 [typec_ucsi]\n    ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi]\n    process_one_work+0x18e/0x3e0\n    worker_thread+0x2e3/0x420\n    kthread+0x10a/0x230\n    ret_from_fork+0x121/0x140\n    ret_from_fork_asm+0x1a/0x30\n\n   With worse timing the same stale pointer is dereferenced after the\n   backing memory is freed, turning the warning into a use-after-free.\n\nFix the asymmetry: call typec_deattach() before clearing\nport_dev-\u003econnector, matching what connector_bind() does on the bind side.\ntypec_partner_deattach() is already protected by port-\u003epartner_link_lock,\nso it serialises safely with the concurrent typec_unregister_partner() path.",
  "id": "GHSA-3j8g-7xhm-68vv",
  "modified": "2026-08-10T15:33:48Z",
  "published": "2026-08-10T15:33:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68372"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7714fb896ed308cf13d32d317040adc4f200b8e4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/78d361e60caf1999d51bda0e1b1004f5d39fcfbc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e00109b5adf71635919248e9ab6300a662e6a3e8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e0b291fe117964037e0ba382eff4bb365d531c3a"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…