CVE-2026-64396: Linux kernel · Use After Free
Source GCVE Database
Not known to be exploited · CVSS 8.8 High.
Data as of 26 Oct 2026, 17:16 UTC
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 37% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 25 Jul 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
AI-suggested
The vulnerability has been resolved in the Linux kernel by restructuring the cleanup logic in ksmbd. Users and administrators should monitor official Linux kernel advisories and apply updates when available to mitigate this issue.
Description
In 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().
References
- nvd.nist.gov/vuln/detail/CVE-2026-64396 (opens in a new tab)
- git.kernel.org/stable/c/367c42a611fe488b7b03f1f6737f4dee0e8b20a2 (opens in a new tab)
- git.kernel.org/stable/c/463bbd79698513af4dad50fe1c573825f297ca2e (opens in a new tab)
- git.kernel.org/stable/c/5aa1cb01155f96824003baf7997cdf1f150caba3 (opens in a new tab)
- git.kernel.org/stable/c/5c75275c0fc9a2deb0d8f5604edcb16f288171c8 (opens in a new tab)
- git.kernel.org/stable/c/7703fd9aba1f2483c8e55f9ff73b7663e0761ed9 (opens in a new tab)
- git.kernel.org/stable/c/d20d1c8ba5765d1d12eefc0aee6385ab3f240e1e (opens in a new tab)