{ "schema_version": "1.6.1", "id": "RPI-CVE-2025-38174", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2025-38174" ], "published": "2025-07-04T10:40:13Z", "summary": "thunderbolt: Do not double dequeue a configuration request", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nthunderbolt: Do not double dequeue a configuration request\n\nSome of our devices crash in tb_cfg_request_dequeue():\n\n general protection fault, probably for non-canonical address 0xdead000000000122\n\n CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65\n RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0\n Call Trace:\n \n ? tb_cfg_request_dequeue+0x2d/0xa0\n tb_cfg_request_work+0x33/0x80\n worker_thread+0x386/0x8f0\n kthread+0xed/0x110\n ret_from_fork+0x38/0x50\n ret_from_fork_asm+0x1b/0x30\n\nThe circumstances are unclear, however, the theory is that\ntb_cfg_request_work() can be scheduled twice for a request:\nfirst time via frame.callback from ring_work() and second\ntime from tb_cfg_request(). Both times kworkers will execute\ntb_cfg_request_dequeue(), which results in double list_del()\nfrom the ctl->request_queue (the list poison deference hints\nat it: 0xdead000000000122).\n\nDo not dequeue requests that don't have TB_CFG_REQUEST_ACTIVE\nbit set.", "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.142", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2025-38174" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/e49e994cd83705f7ca30eda1e304abddfd96a37a" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/0a3011d47dbc92a33621861c423cb64833d7fe57" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/2f62eda4d974c26bc595425eafd429067541f2c9" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/85286e634ebbaf9c0fb1cdf580add2f33fc7628c" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/5a057f261539720165d03d85024da2b52e67f63d" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/eb2d5e794fb966b3ef8bde99eb8561446a53509f" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/0771bcbe2f6e5d5f263cf466efe571d2754a46da" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/cdb4feab2f39e75a66239e3a112beced279612a8" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/0f73628e9da1ee39daf5f188190cdbaee5e0c98c" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T12:19:11Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 8.8, "cvss_v3_severity": "High", "scenario": "AV:A - The vulnerable control-channel request queue is driven by packets received over the Thunderbolt/USB4 fabric, and the trigger is fully reachable by a peer host or device on the other end of a Thunderbolt link via the XDomain protocol (`tb_xdomain_handle_request()` \u2192 `tb_xdp_handle_request()` \u2192 `__tb_xdomain_response()`), matching the adjacent-topology model used for other Thunderbolt XDomain issues.\nAC:L - The attacker controls both sides of the race \u2014 it elicits the host's XDomain response (which is queued with `TB_CFG_REQUEST_ACTIVE` and immediately `schedule_work()`ed because `req->response` is NULL) and then injects a matching `XDOMAIN_RESP`/`ERROR` packet to schedule the same work a second time, with unlimited retries and no attacker-independent preconditions.\nPR:N - XDomain discovery requests are processed and answered before any device authorization or security-level gate (UUID/unknown-type requests are answered even when no `tb_xdomain` is registered), so no credentials or privileges on the target are required.\nUI:N - Once a Thunderbolt link exists (dock, daisy chain, host-to-host cable, or a device the attacker attaches), the attack proceeds purely from attacker-sent control packets with no action by the local user.\nS:U - The corruption and its consequences are confined to the kernel's own security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - The duplicated work run drops an extra `tb_cfg_request_put()`, freeing the request while a second `tb_cfg_request_work()` still reads it \u2014 a use-after-free on a ~192\u2013256 byte kmalloc object that, combined with the attacker-controlled `kmemdup()` spray in `tb_xdp_schedule_request()`, yields a kernel memory disclosure primitive.\nI:H - The second run of the work item calls `req->callback(req->callback_data)` and `mutex_lock(&req->ctl->request_queue_lock)`/`list_del()` on freed, reallocatable memory, giving an indirect call through an attacker-groomed function pointer plus list-based write primitives, i.e. potential control-flow hijack.\nA:H - The reported and readily reproduced outcome is a general protection fault in a kworker from the double `list_del()` on list poison, killing the worker while holding `ctl->request_queue_lock`, which oopses the kernel and wedges the Thunderbolt control channel." } } }