GHSA-W2FG-C334-XW3Q
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-07-27 06:30In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock cancellation
When a blocking byte-range lock request is deferred in the FILE_LOCK_DEFERRED path, ksmbd registers the asynchronous work into the connection's async_requests list via setup_async_work(). The cancel callback smb2_remove_blocked_lock() holds a reference to the flock.
If the lock waiter is subsequently woken up but the work state is no longer KSMBD_WORK_ACTIVE (e.g., due to a concurrent cancellation), the cleanup path calls locks_free_lock(flock) without dequeuing the work from the async_requests list. Concurrently, smb2_cancel() walks the list under conn->request_lock and invokes the cancel callback, which then dereferences the already freed 'flock'. This leads to a slab-use-after-free inside __wake_up_common.
Fix this by restructuring the cleanup logic after the worker returns from ksmbd_vfs_posix_lock_wait(). Move list_del(&smb_lock->llist) and release_async_work(work) to the top of the cleanup block. This guarantees that the async work is completely dequeued and serialized under conn->request_lock before locks_free_lock(flock) is called, rendering the flock unreachable for any concurrent smb2_cancel().
{
"affected": [],
"aliases": [
"CVE-2026-64396"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:23Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock cancellation\n\nWhen a blocking byte-range lock request is deferred in the\nFILE_LOCK_DEFERRED path, ksmbd registers the asynchronous work into\nthe connection\u0027s async_requests list via setup_async_work(). The cancel\ncallback smb2_remove_blocked_lock() holds a reference to the flock.\n\nIf the lock waiter is subsequently woken up but the work state is no\nlonger KSMBD_WORK_ACTIVE (e.g., due to a concurrent cancellation), the\ncleanup path calls locks_free_lock(flock) without dequeuing the work from\nthe async_requests list. Concurrently, smb2_cancel() walks the list\nunder conn-\u003erequest_lock and invokes the cancel callback, which then\ndereferences the already freed \u0027flock\u0027. This leads to a slab-use-after-free\ninside __wake_up_common.\n\nFix this by restructuring the cleanup logic after the worker returns\nfrom ksmbd_vfs_posix_lock_wait(). Move list_del(\u0026smb_lock-\u003ellist) and\nrelease_async_work(work) to the top of the cleanup block. This guarantees\nthat the async work is completely dequeued and serialized under\nconn-\u003erequest_lock before locks_free_lock(flock) is called, rendering\nthe flock unreachable for any concurrent smb2_cancel().",
"id": "GHSA-w2fg-c334-xw3q",
"modified": "2026-07-27T06:30:36Z",
"published": "2026-07-25T12:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64396"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/367c42a611fe488b7b03f1f6737f4dee0e8b20a2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/463bbd79698513af4dad50fe1c573825f297ca2e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5aa1cb01155f96824003baf7997cdf1f150caba3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5c75275c0fc9a2deb0d8f5604edcb16f288171c8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7703fd9aba1f2483c8e55f9ff73b7663e0761ed9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d20d1c8ba5765d1d12eefc0aee6385ab3f240e1e"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
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.