Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then SMB2_CANCEL… (CVE-2026-64437)
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then SMB2_CANCEL Commit f580d27e8928 ("ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL") made smb2_cancel() skip a work whose state is KSMBD_WORK_CANCELLED, so its cancel_fn cannot be fired a second time. But KSMBD_WORK has three states (ACTIVE, CANCELLED, CLOSED), and the same freeing producer path is reached for CLOSED too: SMB2_CLOSE on the locking handle -> set_close_state_blocked_works() sets the deferred work's state to KSMBD_WORK_CLOSED and wakes the smb2_lock() worker. The worker takes the non-ACTIVE early-exit, locks_free_lock()s the file_lock and, because the state is not KSMBD_WORK_CANCELLED, takes the STATUS_RANGE_NOT_LOCKED branch with "goto out2" -- which, like the cancelled branch, skips release_async_work(). The work stays on conn->async_requests with a live cancel_fn = smb2_remove_blocked_lock pointing at the freed file_lock. A subsequent SMB2_CANCEL for the same AsyncId then passes the KSMBD_WORK_CANCELLED-only guard (its state is KSMBD_WORK_CLOSED), so smb2_cancel() fires cancel_fn again over the freed file_lock -- the same use-after-free fixed, via SMB2_CLOSE instead of a first SMB2_CANCEL: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (non-ACTIVE early-exit) ... cache file_lock_cache of size 192 Reproduced on mainline 7.1-rc7 (which already contains f580d27e8928) with KASAN by an authenticated SMB client; the double-SMB2_CANCEL control is silent on that kernel, so the splat is attributable to the CLOSE trigger. Only an ACTIVE deferred work may have its cancel_fn fired: both terminal states (CANCELLED and CLOSED) reach the smb2_lock() early-exit that frees the file_lock and skips release_async_work(). Guard on KSMBD_WORK_ACTIVE so any non-active work is skipped.
AI Analysis
Technical Summary
The Linux kernel ksmbd component had a use-after-free vulnerability involving deferred file_lock objects during SMB2_CLOSE followed by SMB2_CANCEL operations. The problem arises because the deferred work's state transitions to CLOSED, freeing the file_lock but leaving a live cancel function pointer. A subsequent SMB2_CANCEL call then triggers this cancel function on the freed file_lock, causing a use-after-free. The issue was reproduced with KASAN on kernel 7.1-rc7. The fix involves ensuring that only ACTIVE deferred work has its cancel function fired, skipping non-active states (CANCELLED and CLOSED) to prevent double freeing and use-after-free conditions.
Potential Impact
This vulnerability can lead to kernel memory corruption due to use-after-free of file_lock structures in the ksmbd SMB server. Exploitation could cause kernel crashes or instability. The vulnerability requires an authenticated SMB client to trigger the condition. There is no evidence of known exploits in the wild at this time.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Since this is a kernel vulnerability, applying the latest Linux kernel updates that include the fix for CVE-2026-64437 is recommended once available. Until then, restricting SMB client access to trusted users may reduce risk.
Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then SMB2_CANCEL… (CVE-2026-64437)
Description
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then SMB2_CANCEL Commit f580d27e8928 ("ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL") made smb2_cancel() skip a work whose state is KSMBD_WORK_CANCELLED, so its cancel_fn cannot be fired a second time. But KSMBD_WORK has three states (ACTIVE, CANCELLED, CLOSED), and the same freeing producer path is reached for CLOSED too: SMB2_CLOSE on the locking handle -> set_close_state_blocked_works() sets the deferred work's state to KSMBD_WORK_CLOSED and wakes the smb2_lock() worker. The worker takes the non-ACTIVE early-exit, locks_free_lock()s the file_lock and, because the state is not KSMBD_WORK_CANCELLED, takes the STATUS_RANGE_NOT_LOCKED branch with "goto out2" -- which, like the cancelled branch, skips release_async_work(). The work stays on conn->async_requests with a live cancel_fn = smb2_remove_blocked_lock pointing at the freed file_lock. A subsequent SMB2_CANCEL for the same AsyncId then passes the KSMBD_WORK_CANCELLED-only guard (its state is KSMBD_WORK_CLOSED), so smb2_cancel() fires cancel_fn again over the freed file_lock -- the same use-after-free fixed, via SMB2_CLOSE instead of a first SMB2_CANCEL: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (non-ACTIVE early-exit) ... cache file_lock_cache of size 192 Reproduced on mainline 7.1-rc7 (which already contains f580d27e8928) with KASAN by an authenticated SMB client; the double-SMB2_CANCEL control is silent on that kernel, so the splat is attributable to the CLOSE trigger. Only an ACTIVE deferred work may have its cancel_fn fired: both terminal states (CANCELLED and CLOSED) reach the smb2_lock() early-exit that frees the file_lock and skips release_async_work(). Guard on KSMBD_WORK_ACTIVE so any non-active work is skipped.
CVSS v3.1
Score 8.8high
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel ksmbd component had a use-after-free vulnerability involving deferred file_lock objects during SMB2_CLOSE followed by SMB2_CANCEL operations. The problem arises because the deferred work's state transitions to CLOSED, freeing the file_lock but leaving a live cancel function pointer. A subsequent SMB2_CANCEL call then triggers this cancel function on the freed file_lock, causing a use-after-free. The issue was reproduced with KASAN on kernel 7.1-rc7. The fix involves ensuring that only ACTIVE deferred work has its cancel function fired, skipping non-active states (CANCELLED and CLOSED) to prevent double freeing and use-after-free conditions.
Potential Impact
This vulnerability can lead to kernel memory corruption due to use-after-free of file_lock structures in the ksmbd SMB server. Exploitation could cause kernel crashes or instability. The vulnerability requires an authenticated SMB client to trigger the condition. There is no evidence of known exploits in the wild at this time.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Since this is a kernel vulnerability, applying the latest Linux kernel updates that include the fix for CVE-2026-64437 is recommended once available. Until then, restricting SMB client access to trusted users may reduce risk.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-x5p7-hg5v-9p54
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-64437"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a6542099c2644c7f80832b2
Added to database: 07/25/2026, 23:08:57 UTC
Last enriched: 07/25/2026, 23:21:58 UTC
Last updated: 09/08/2026, 22:52:14 UTC
Views: 65
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.