GHSA-VPMX-4VX6-75FP

Vulnerability from github – Published: 2026-10-18 18:32 – Updated: 2026-10-30 15:33
VLAI
Details

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

Show details on source website

{
  "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": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

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.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
Events included in the timeline

Loading timeline…


    Loading…

    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.