CVE-2026-53198

What it actually does

This is a use-after-free flaw in the Linux kernel ksmbd SMB server. An authenticated SMB client can create a deferred byte-range lock, cancel it, and then send a second SMB2_CANCEL for the same asynchronous request. Because the cancelled async work remains on the connection's async request list with a callback argument pointing to a freed struct file_lock, the second cancel can invoke the callback on freed kernel memory. The demonstrated impact is a kernel slab use-after-free in the file locking path, likely causing kernel warning/oops, service crash, or host denial of service; as with kernel use-after-free issues, memory corruption risk should be treated seriously even if reliable code execution is not currently demonstrated.

Why it matters to the business

Systems using the in-kernel ksmbd SMB server may be vulnerable to a remotely triggered crash or instability by any attacker with valid SMB access. This can interrupt file sharing, affect applications or users depending on SMB shares, and in severe cases cause host outages. The vulnerability is not currently in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS probability, and has no public exploit maturity reported, but exposure should still be addressed because the affected component runs in the kernel and SMB services are often business-critical.

How an attack unfolds

An attacker first needs network reachability to an SMB service implemented by Linux kernel ksmbd and must authenticate as an SMB client. The attacker establishes an SMB session, issues an SMB2_LOCK request that becomes blocked and is converted into deferred asynchronous work, then sends an SMB2_CANCEL for that AsyncId. The first cancel frees the associated file_lock but leaves the async work entry still matchable on the connection list with a stale cancel callback argument. Before the connection is torn down, the attacker sends a second SMB2_CANCEL for the same AsyncId. The server invokes the cancel callback again using the freed file_lock pointer, triggering a kernel use-after-free in the file-lock deletion/unblock path. Practical outcomes are expected to include ksmbd failure, kernel oops/panic, or denial of service; privilege escalation or remote code execution has not been established from the provided information.

How to fix it

Apply the Linux kernel update that contains the ksmbd fix for this issue from the relevant Linux distribution or kernel vendor. No exact fixed package versions were provided, so track vendor advisories for the specific distribution, kernel branch, appliance, or embedded product in use. If ksmbd is not required, disable it and use an alternative supported SMB service or remove the ksmbd module/package where applicable. As compensating controls, restrict TCP/445 exposure to trusted networks, require strong SMB authentication, limit SMB accounts to least privilege, and monitor for abnormal SMB cancel/lock behavior. Systems using user-space Samba rather than kernel ksmbd are not necessarily affected by this ksmbd-specific bug, but should still be verified by product and vendor guidance.

How to confirm the fix worked

Confirm whether the host is running kernel ksmbd rather than only user-space Samba by checking loaded modules, ksmbd service state, kernel configuration, and SMB server processes. Validate that the installed kernel package includes the vendor fix for the double SMB2_CANCEL use-after-free condition. After patching, reboot into the updated kernel if required and confirm the running kernel version, not only the installed package version. Verify that ksmbd is disabled if it is not intended to be used. Exposure can be checked by scanning for SMB on TCP/445 and correlating exposed services with hosts where ksmbd is enabled. In test environments only, a safe vendor-provided regression test or kernel self-test should confirm that duplicate cancel handling no longer re-invokes the blocked-lock cancellation callback.

Typical attack path

1. Identify a Linux host exposing SMB over TCP/445 using the in-kernel ksmbd server.
2. Authenticate to the SMB service with valid credentials or reuse compromised SMB credentials.
3. Open or access a share in a way that permits issuing SMB2 byte-range lock operations.
4. Send an SMB2_LOCK request that blocks and creates deferred asynchronous work for the connection.
5. Send an SMB2_CANCEL for the deferred lock request's AsyncId, causing the lock object to be freed.
6. Send a second SMB2_CANCEL for the same AsyncId before connection teardown.
7. Trigger use-after-free in the ksmbd file-lock cancellation path, potentially crashing or destabilizing the kernel.

How to detect it

Look for evidence of prior exploitation in kernel logs, system journals, crash dumps, SMB service logs, authentication logs, and network telemetry. The most direct host indicators are kernel oops, panic, KASAN, or slab use-after-free messages involving ksmbd, smb2_cancel, smb2_remove_blocked_lock, ksmbd_vfs_posix_lock_unblock, locks_delete_block, or __locks_delete_block. Production systems may not run KASAN, so also investigate unexplained reboots, ksmbd worker crashes, soft lockups, or kernel panics that coincide with authenticated SMB sessions. In network logs or packet captures, search for SMB2_LOCK requests followed by repeated SMB2_CANCEL messages for the same session/tree/request AsyncId, particularly when followed by connection resets or host failure. Correlate suspicious SMB activity with authentication logs to identify the SMB account and source IP used shortly before the crash. If kdump/vmcore is available, analyze the stack trace for the ksmbd cancel path and freed file_lock objects. Absence of these artifacts does not prove non-exploitation, especially if kernel crash dumps and detailed SMB packet logging were not enabled.

• BUG: KASAN: slab-use-after-free in __locks_delete_block
• 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
• handle_ksmbd_work
• locks_alloc_lock
• locks_free_lock
• file_lock_cache
• KSMBD_WORK_CANCELLED
• SMB2_CANCEL
• SMB2_LOCK
• ksmbd:
• kernel BUG
• Kernel panic
• Oops:

What your security team should do

• Inventory Linux systems exposing SMB and identify which ones use kernel ksmbd.
• Prioritize patching or disabling ksmbd on internet-facing, untrusted-network-facing, and business-critical file-sharing systems.
• Restrict TCP/445 access at network boundaries and host firewalls to only required clients and administrative networks.
• Review SMB authentication sources for weak, shared, stale, or externally exposed credentials because exploitation requires authenticated SMB access.
• Enable or centralize kernel, systemd journal, and SMB-related logging for ksmbd hosts to detect crashes, oops events, and suspicious SMB session behavior.
• Monitor for repeated SMB2_CANCEL activity, especially duplicate cancels for the same async request/session where packet telemetry is available.
• If unexplained kernel crashes occurred on ksmbd hosts, preserve logs, vmcore/kdump artifacts, and network telemetry before rebooting or rebuilding.
• Track Linux distribution security advisories for the exact fixed kernel versions because fixed package versions were not supplied in the input.