CVE-2026-53198: Linux ksmbd Use-After-Free via SMB2_CANCEL DoS
A memory safety bug in the Linux kernel's ksmbd (kernel SMB daemon) file-locking code can be exploited to crash the system or potentially execute code. The vulnerability occurs when a network-connected attacker sends two specially-crafted SMB2 cancellation commands targeting the same lock request in rapid succession. This causes the kernel to access memory that has already been freed, leading to memory corruption. An attacker must be authenticated to the SMB service to exploit this issue.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 8.8 HIGH · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Weaknesses (CWE)
- CWE-416
- Affected products
- 7 configuration(s)
- Published / Modified
- 2026-06-25 / 2026-07-06
NVD description (verbatim)
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which "goto out"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: 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 (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.
6 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
CVE-2026-53198 is a use-after-free vulnerability in ksmbd's SMB2_LOCK and SMB2_CANCEL handling. When a byte-range lock request is deferred (blocked), it registers an async work queue entry with a cancel callback (smb2_remove_blocked_lock) that holds a pointer to a file_lock structure. If the lock request is cancelled, the file_lock is freed via locks_free_lock(), but the work queue entry is not properly unlinked from conn->async_requests and its cancel callback is not cleared. A subsequent SMB2_CANCEL message targeting the same AsyncId will then invoke the stale cancel callback against the freed memory. The fix prevents this by checking the work's state flag (KSMBD_WORK_CANCELLED) before invoking cancel callbacks, ensuring a callback fires at most once.
Business impact
This vulnerability can disrupt SMB-based file sharing and collaboration services. Authenticated attackers on the network can trigger kernel panics, resulting in unplanned downtime and service unavailability. While remote code execution is theoretically possible via heap corruption, practical exploitation would depend on precise memory layout and kernel protections in the target environment. Organizations relying on Samba or SMB services for file sharing, backup, or archival are at risk.
Affected systems
The Linux kernel is affected, specifically the ksmbd subsystem. This impacts systems running Linux kernels with ksmbd enabled that expose SMB services (including Samba deployments that use ksmbd). Kernels prior to the fix commit are vulnerable. Specific patched version numbers should be verified against kernel.org and vendor advisories, as the data provided does not include exact version boundaries.
Exploitability
Exploitation requires network access to an SMB service and valid authentication credentials. The attack is not complex—two precisely-timed SMB2_CANCEL messages are needed—making it achievable by attackers with legitimate SMB access. The condition window is tight but reproducible, as evidenced by KASAN-based testing. No public exploit code or active in-the-wild exploitation is currently documented.
Remediation
Apply a kernel patch that adds a state check to smb2_cancel(), preventing the cancellation callback from being invoked on work already marked KSMBD_WORK_CANCELLED. System administrators should update their Linux kernels and, if applicable, Samba/SMB services to versions incorporating the fix. Patched kernel versions should be identified from linux-kernel.org and your distribution's security advisories.
Patch guidance
Monitor your Linux kernel version and check kernel.org security advisories and your distribution's kernel package updates for patches addressing this CVE. If you maintain custom kernel builds, incorporate the fix that adds a state guard check in smb2_cancel(). For Samba users on ksmbd-enabled systems, ensure your kernel is up to date before updating Samba itself, as the fix is kernel-level. Testing in a non-production environment is recommended before kernel updates to rule out compatibility issues.
Detection guidance
Watch for kernel logs containing KASAN reports referencing slab-use-after-free in __locks_delete_block, locks_delete_block, or smb2_remove_blocked_lock. Monitor SMB service logs (via syslog or auditd) for unusual patterns of SMB2_CANCEL messages sent in rapid succession by authenticated users targeting lock operations. Kernel crash dumps with stack traces pointing to the ksmbd locking code are strong indicators of exploitation attempts.
Why prioritize this
This is a HIGH-severity vulnerability affecting a widely-used network service. The combination of authenticated-but-easy-to-exploit attack surface, potential for denial-of-service (and theoretical code execution via heap corruption), and the prevalence of SMB services in enterprise environments makes this a priority. Organizations with ksmbd-enabled SMB services should patch promptly. The fact that it requires authentication slightly reduces urgency compared to unauthenticated RCE, but DoS impact on critical file services justifies rapid remediation.
Risk score, explained
CVSS 3.1 score of 8.8 (HIGH) reflects: (1) Network-accessible attack vector, (2) Low complexity (two timed SMB messages), (3) Requires Low privilege (SMB authentication), (4) High impact on confidentiality, integrity, and availability via memory corruption and kernel panic. The lack of user interaction and lack of scope change keep it from CRITICAL. Real-world impact hinges on the prevalence of ksmbd vs. userspace Samba and the network position of attackers relative to SMB services.
Frequently asked questions
Do I need to be an SMB user to exploit this, or just authenticated?
You must be able to authenticate to the SMB service. This means you need valid credentials (username/password or other auth method configured on the target). You do not necessarily need a live file share or the ability to read/write files; the vulnerability lives in the lock-handling code path, which is exercised by any authenticated SMB session that issues lock commands.
Is this vulnerability in Samba (userspace) or only in ksmbd (kernel)?
This specific vulnerability is in ksmbd, the in-kernel SMB server. Samba (userspace) has a different code path and is not affected by this particular issue. However, some Linux distributions and products use ksmbd for SMB services, so determine which implementation your environment uses before assessing impact.
What does 'use-after-free' mean in practical terms?
Use-after-free means the kernel is writing to or reading from memory that has been returned to the free pool. This can cause crashes (DoS), information leaks, or—under certain conditions and with careful exploitation—code execution. In this case, the freed memory is a file_lock structure, and re-accessing it can corrupt kernel heap state or trigger a panic.
Will applying other kernel security patches fix this, or do I need a specific update?
This vulnerability requires a targeted fix in ksmbd's SMB2_CANCEL handler. While keeping your kernel fully patched is always good practice, you should specifically check your kernel version against advisories for CVE-2026-53198 to confirm the fix is included. Do not assume a general kernel update includes this patch.
This analysis is provided for informational purposes and represents conditions as of the CVE publication date. Specific patch versions, affected kernel branches, and vendor release timelines should be verified against kernel.org, your Linux distribution's security advisories, and vendor security bulletins. No guarantee is made regarding exploit availability, real-world prevalence, or applicability to custom or hardened kernels. Always test patches in a non-production environment before production deployment. The vulnerability information herein does not constitute legal advice or a substitute for professional security assessment. Source: NVD (public-domain), retrieved 2026-08-03. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2026-10001HIGHChrome Sandbox Escape via PerformanceManager Use-After-Free
- CVE-2026-10002HIGHGoogle Chrome PDFium Use-After-Free Vulnerability (CVSS 8.8)
- CVE-2026-10003HIGHChrome Use-After-Free Code Execution Vulnerability Analysis
- CVE-2026-10007HIGHChrome Use-After-Free in SVG Arbitrary Code Execution (CVSS 8.8)
- CVE-2026-10012HIGHChrome Skia Use-After-Free Sandbox Escape (v148.0.7778.216)
- CVE-2026-10013HIGHUse-After-Free in Chrome WebCodecs – Patch Guide & Risk Assessment
- CVE-2026-10016HIGHUse-After-Free in Chrome DOM – Sandbox Code Execution Vulnerability
- CVE-2026-10882HIGHCritical Chrome Use-After-Free RCE Vulnerability – Exploit Details & Patch Guidance