GHSA-FXM4-5828-J89M
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-08-12 18:31In the Linux kernel, the following vulnerability has been resolved:
fuse-uring: end fuse_req on io-uring cancel task work
When io_uring delivers task work with tw.cancel set (PF_EXITING, PF_KTHREAD fallback, or percpu_ref_is_dying on the ring context), fuse_uring_send_in_task() takes the cancel branch, assigns -ECANCELED, and falls through to fuse_uring_send(). That path only flips the entry to FRRS_USERSPACE and completes the io_uring cmd; it never discharges the ring entry's owning reference to the fuse_req that fuse_uring_add_req_to_ring_ent() handed it at dispatch time.
fuse_uring_send_in_task()
tw.cancel == true
err = -ECANCELED
fuse_uring_send(ent, cmd, err, issue_flags)
ent->state = FRRS_USERSPACE
list_move(&ent->list, &queue->ent_in_userspace)
ent->cmd = NULL
io_uring_cmd_done(-ECANCELED)
/* ent->fuse_req still set, req still hashed */
The fuse_req stays linked on fpq->processing[hash] and fuse_request_end() is never invoked. The originating syscall thread blocks in D-state in request_wait_answer() until fuse_abort_conn() runs, which can be the entire connection lifetime. For FR_BACKGROUND requests fc->num_background is never decremented either, so repeated cancels inflate the counter until max_background is hit and all later background ops stall. tw.cancel does not imply a connection abort (e.g. a single io_uring worker thread exits while the fuse connection stays up), so this cannot be left for fuse_abort_conn() to clean up.
Ending the req but still routing the entry through fuse_uring_send() is not enough: that leaves a req-less entry on ent_in_userspace, and ent_list_request_expired() dereferences ent->fuse_req unconditionally on the head of that list, which would then NULL-deref.
Fix the cancel branch to release the entry directly. Remove it from the queue, complete the io_uring cmd, end the fuse_req, free the entry, and drop its queue_refs (waking the teardown waiter if it was the last).
{
"affected": [],
"aliases": [
"CVE-2026-64262"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfuse-uring: end fuse_req on io-uring cancel task work\n\nWhen io_uring delivers task work with tw.cancel set (PF_EXITING,\nPF_KTHREAD fallback, or percpu_ref_is_dying on the ring context),\nfuse_uring_send_in_task() takes the cancel branch, assigns\n-ECANCELED, and falls through to fuse_uring_send(). That path only\nflips the entry to FRRS_USERSPACE and completes the io_uring cmd;\nit never discharges the ring entry\u0027s owning reference to the\nfuse_req that fuse_uring_add_req_to_ring_ent() handed it at\ndispatch time.\n\n fuse_uring_send_in_task()\n tw.cancel == true\n err = -ECANCELED\n fuse_uring_send(ent, cmd, err, issue_flags)\n ent-\u003estate = FRRS_USERSPACE\n list_move(\u0026ent-\u003elist, \u0026queue-\u003eent_in_userspace)\n ent-\u003ecmd = NULL\n io_uring_cmd_done(-ECANCELED)\n /* ent-\u003efuse_req still set, req still hashed */\n\nThe fuse_req stays linked on fpq-\u003eprocessing[hash] and\nfuse_request_end() is never invoked. The originating syscall\nthread blocks in D-state in request_wait_answer() until\nfuse_abort_conn() runs, which can be the entire connection\nlifetime. For FR_BACKGROUND requests fc-\u003enum_background is never\ndecremented either, so repeated cancels inflate the counter until\nmax_background is hit and all later background ops stall. tw.cancel does\nnot imply a connection abort (e.g. a single io_uring worker thread exits\nwhile the fuse connection stays up), so this cannot be left for\nfuse_abort_conn() to clean up.\n\nEnding the req but still routing the entry through fuse_uring_send()\nis not enough: that leaves a req-less entry on ent_in_userspace, and\nent_list_request_expired() dereferences ent-\u003efuse_req unconditionally\non the head of that list, which would then NULL-deref.\n\nFix the cancel branch to release the entry directly. Remove it from the\nqueue, complete the io_uring cmd, end the fuse_req, free the entry, and\ndrop its queue_refs (waking the teardown waiter if it was the last).",
"id": "GHSA-fxm4-5828-j89m",
"modified": "2026-08-12T18:31:03Z",
"published": "2026-07-25T12:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64262"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4f45f276d5b4412eade6f74f2e37f3adba0473ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bb476ef8e1027a9d509fbaaf81f5061a07e9e5a7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bea4fe98204b6ce7eb8e29f7bf867dd7619b3ddd"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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.
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.