GHSA-VPMX-4VX6-75FP
Vulnerability from github – Published: 2026-10-18 18:32 – Updated: 2026-10-30 15:33In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Fix KASAN reported use-after-free when request is canceled
Alan reported that when doing stress testing sometimes KASAN notices use-after-free during control channel operation (stripped down keeping the relevant parts):
BUG: KASAN: slab-use-after-free in tb_cfg_request_sync+0x240/0x250 [thunderbolt] Read of size 24 at addr ffff88811067f290 by task kworker/u40:2/1760 tb_cfg_request_sync+0x240/0x250 [thunderbolt] tb_cfg_read_raw+0x367/0x510 [thunderbolt] tb_cfg_read+0xec/0x240 [thunderbolt] tb_port_get_link_generation+0x258/0x420 [thunderbolt] tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt] tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt] tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt] tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt] tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt] process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30
Allocated by task 1760: __kmalloc_cache_noprof+0x1ee/0x550 tb_cfg_read_raw+0x1d3/0x510 [thunderbolt] tb_cfg_read+0xec/0x240 [thunderbolt] tb_port_get_link_generation+0x258/0x420 [thunderbolt] tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt] tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt] tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt] tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt] tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt] process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30
Freed by task 926: kfree+0x18f/0x4a0 tb_cfg_request_put+0xb7/0xe0 [thunderbolt] tb_cfg_request_work+0x82/0x120 [thunderbolt] process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30
Second to last potentially related work creation: __queue_work+0x575/0xd00 queue_work_on+0x77/0x80 tb_cfg_request_cancel+0xc7/0x260 [thunderbolt] tb_cfg_request_sync+0x1f6/0x250 [thunderbolt] tb_cfg_read_raw+0x367/0x510 [thunderbolt] tb_cfg_read+0xec/0x240 [thunderbolt] tb_port_get_link_generation+0x258/0x420 [thunderbolt] tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt] tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt] tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt] tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt] tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt] process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30
The last stack trace is helpful because it shows that we are cancelling a request and looking at tb_cfg_request_cancel() what might happen is that tb_cfg_request_work() completes right before tb_cfg_request_cancel() starts and because of this it will call schedule_work() queueing the same work to run again. However, it is already removed from the request_queue and reference count is dropped so when tb_cfg_request_work() triggers again it will access memory that is already released.
Fix this so that we first make sure a cancelled request is not handed away from tb_cfg_request_find() or scheduled to run. Then instead of relying on the worker to clean up the request we will do it in tb_cfg_request_cancel() after the work is canceled from running. Make tb_cfg_request_dequeue() release the request only if it was actually removed from the queue.
{
"affected": [],
"aliases": [
"CVE-2026-98694"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-18T16:17:22Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nthunderbolt: Fix KASAN reported use-after-free when request is canceled\n\nAlan reported that when doing stress testing sometimes KASAN notices\nuse-after-free during control channel operation (stripped down keeping\nthe relevant parts):\n\n BUG: KASAN: slab-use-after-free in tb_cfg_request_sync+0x240/0x250 [thunderbolt]\n Read of size 24 at addr ffff88811067f290 by task kworker/u40:2/1760\n \u003cTASK\u003e\n tb_cfg_request_sync+0x240/0x250 [thunderbolt]\n tb_cfg_read_raw+0x367/0x510 [thunderbolt]\n tb_cfg_read+0xec/0x240 [thunderbolt]\n tb_port_get_link_generation+0x258/0x420 [thunderbolt]\n tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt]\n tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt]\n tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt]\n tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt]\n tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt]\n process_one_work+0x675/0x1230\n worker_thread+0x5e6/0xf70\n kthread+0x365/0x470\n ret_from_fork+0x54d/0x710\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n\n Allocated by task 1760:\n __kmalloc_cache_noprof+0x1ee/0x550\n tb_cfg_read_raw+0x1d3/0x510 [thunderbolt]\n tb_cfg_read+0xec/0x240 [thunderbolt]\n tb_port_get_link_generation+0x258/0x420 [thunderbolt]\n tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt]\n tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt]\n tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt]\n tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt]\n tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt]\n process_one_work+0x675/0x1230\n worker_thread+0x5e6/0xf70\n kthread+0x365/0x470\n ret_from_fork+0x54d/0x710\n ret_from_fork_asm+0x1a/0x30\n\n Freed by task 926:\n kfree+0x18f/0x4a0\n tb_cfg_request_put+0xb7/0xe0 [thunderbolt]\n tb_cfg_request_work+0x82/0x120 [thunderbolt]\n process_one_work+0x675/0x1230\n worker_thread+0x5e6/0xf70\n kthread+0x365/0x470\n ret_from_fork+0x54d/0x710\n ret_from_fork_asm+0x1a/0x30\n\n Second to last potentially related work creation:\n __queue_work+0x575/0xd00\n queue_work_on+0x77/0x80\n tb_cfg_request_cancel+0xc7/0x260 [thunderbolt]\n tb_cfg_request_sync+0x1f6/0x250 [thunderbolt]\n tb_cfg_read_raw+0x367/0x510 [thunderbolt]\n tb_cfg_read+0xec/0x240 [thunderbolt]\n tb_port_get_link_generation+0x258/0x420 [thunderbolt]\n tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt]\n tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt]\n tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt]\n tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt]\n tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt]\n process_one_work+0x675/0x1230\n worker_thread+0x5e6/0xf70\n kthread+0x365/0x470\n ret_from_fork+0x54d/0x710\n ret_from_fork_asm+0x1a/0x30\n\nThe last stack trace is helpful because it shows that we are cancelling\na request and looking at tb_cfg_request_cancel() what might happen is\nthat tb_cfg_request_work() completes right before tb_cfg_request_cancel()\nstarts and because of this it will call schedule_work() queueing the\nsame work to run again. However, it is already removed from the\nrequest_queue and reference count is dropped so when\ntb_cfg_request_work() triggers again it will access memory that is\nalready released.\n\nFix this so that we first make sure a cancelled request is not handed\naway from tb_cfg_request_find() or scheduled to run. Then instead of\nrelying on the worker to clean up the request we will do it in\ntb_cfg_request_cancel() after the work is canceled from running. Make\ntb_cfg_request_dequeue() release the request only if it was actually\nremoved from the queue.",
"id": "GHSA-vpmx-4vx6-75fp",
"modified": "2026-10-30T15:33:55Z",
"published": "2026-10-18T18:32:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98694"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/08287212b622039212c972806f896f078dfd28e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0dc4296ac0910d3a43d9e105226ace463e475304"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/71b3c517e02af2c46ad58d4b3706b7c3cb24936d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/94358146389d985b809898cc23b1030ff240a25d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9594550e95bcc362027b7ad5f0d5665110f8a7d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a02188ddc24b7872f0c5e0c5873f827318717803"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b70b9c41f240c42bf6e728034537c0fe60c16ef4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f18faa3d3b810d60a3005ae1b1d1866faa67d343"
}
],
"schema_version": "1.4.0",
"severity": []
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
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.