{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-74575", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-74575" ], "published": "2026-08-15T12:28:42Z", "summary": "thunderbolt: Prevent XDomain delayed work use-after-free on disconnect", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nthunderbolt: Prevent XDomain delayed work use-after-free on disconnect\n\ntb_xdp_handle_request() runs on system_wq and queues\nxd->state_work via queue_delayed_work() in three request handlers:\nPROPERTIES_CHANGED_REQUEST, UUID_REQUEST (via start_handshake),\nand LINK_STATE_CHANGE_REQUEST. Similarly, update_xdomain() queues\nxd->properties_changed_work when local properties change.\n\nConcurrently, tb_xdomain_remove() calls stop_handshake() which does\ncancel_delayed_work_sync() on both delayed works. Later,\ntb_xdomain_unregister() calls device_unregister() which eventually\nfrees the xdomain. Since commit 559c1e1e0134 (\"thunderbolt: Run\ntb_xdp_handle_request() in system workqueue\") moved the request\nhandler off tb->wq, the handler and the remove path are no longer\nserialized. If queue_delayed_work() executes after\ncancel_delayed_work_sync() but before the xdomain is freed, the\ndelayed work fires on a freed object.\n\nAdd xd->removing that tb_xdomain_remove() sets under xd->lock\nbefore calling stop_handshake(). Each external queue site holds\nthe same lock and checks removing before calling\nqueue_delayed_work(). This provides the mutual exclusion needed:\neither the queue site acquires the lock first and queues work that\nthe subsequent cancel will see, or the remove path acquires the\nlock first and the queue site observes removing == true and skips\nthe queue.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.184", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-74575" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/d4fa0d544c04dea636bf821ff5582cd7d63e2c34" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/cfbd2dba3d862c9be8c92bea2a357d9ed828a54a" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/dc11d5118f9da6ea28487ffe055de5a0d0734125" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/91b40862a02000f490b63f1d315be3ee31e83871" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/33c0ee18cf8665c974b00f4e0ba769fbc07efe10" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/54a62153c765cd24239cde1f2633f2a2fd005368" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/2aa2cde2cc79a79d8ea4a15be9f4a67fc528ae91" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/2c5d2d3c3f70cde2565d7b279b544893a2035842" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-23T12:46:35Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 8.8, "cvss_v3_severity": "High", "scenario": "AV:A - XDomain discovery packets reach the kernel over the Thunderbolt/USB4 control channel from a connected peer (adjacent host, dock, or inline device) on the shared physical link; no remote IP/network service is involved, but the attacker need not touch the victim chassis if they control the far end of an established TB connection.\nAC:L - The bug is a race between system_wq request handling and disconnect teardown; the peer attacker controls both sides by sending PROPERTIES_CHANGED, UUID, or LINK_STATE_CHANGE requests while forcing unplug/disconnect and can retry timing until delayed work is queued after cancel_delayed_work_sync().\nPR:N - No local account, capability, or root on the victim is required; any malicious or compromised Thunderbolt XDomain peer that can exchange discovery control-plane packets can trigger the vulnerable queue_delayed_work() paths without OS authentication.\nUI:N - During an active XDomain session the peer can send the triggering requests and force link teardown without any further victim action at exploit time; no additional mount, login, or sysfs operation is needed beyond the already-established Thunderbolt link.\nS:U - Impact is kernel heap use-after-free and memory corruption within kernel context; it does not directly cross VM, container, or IOMMU boundaries, though successful exploitation can yield standard local privilege escalation.\nC:H - Use-after-free on struct tb_xdomain lets attacker-influenced delayed work read freed kernel memory, enabling arbitrary kernel information disclosure and kernel pointer leaks that support further exploitation of the corruption primitive.\nI:H - Delayed work on the freed xdomain executes handshake state transitions, property/link updates, and hardware operations on attacker-reclaimed memory, enabling heap grooming and control-flow hijack for arbitrary kernel write/code execution.\nA:H - Accessing freed tb_xdomain via state_work or properties_changed_work causes kernel oops/panic or hang during disconnect, and a peer can repeat disconnect/request storms to deny Thunderbolt/XDomain services." } } }