CVE-2026-53010

What it actually does

This flaw is a use-after-free in the Linux kernel ksmbd SMB server implementation during SMB2 durable handle reconnect processing. During smb2_open, ksmbd may release a reference to a durable file descriptor too early via ksmbd_put_durable_fd(fp). If subsequent error handling or scavenger activity accesses the same file descriptor object, kernel code may dereference freed memory, potentially causing a kernel crash and denial of service. As with kernel use-after-free bugs, memory corruption could theoretically be exploitable for privilege escalation or remote code execution in favorable conditions, but the provided intelligence indicates no known public exploit maturity, no CISA KEV listing, and a low EPSS score of 0.0043.

Why it matters to the business

Organizations using Linux systems that expose ksmbd-based SMB file sharing could face unexpected file service outages or full system crashes if the bug is triggered remotely. The practical risk is currently lower than widely exploited vulnerabilities because it is not listed in KEV, is not known to be used in ransomware campaigns, and has low predicted exploitation likelihood; however, SMB services are often business-critical, and a remotely triggerable kernel crash can still disrupt file access, application workflows, backups, and user productivity.

How an attack unfolds

An attacker would first need network reachability to a Linux host running the in-kernel ksmbd SMB server and sufficient SMB interaction capability to create or reconnect to durable handles. The attacker initiates SMB2 file open activity using durable handle reconnect semantics. During reconnect handling, the vulnerable code path releases the durable file descriptor reference before all later operations and error paths have finished using it. The attacker then attempts to drive the operation into a failure or race condition, such as causing response-buffer pinning failure or overlapping with scavenger cleanup, so that kernel code later accesses fields from the already-freed file descriptor object. The most likely observable result is a kernel oops, panic, ksmbd worker failure, or system/service denial of service. There is no provided evidence of active exploitation, named threat actors, or weaponized exploit availability as of 48 days after publication.

How to fix it

Apply the Linux kernel update that contains the ksmbd fix moving the durable file descriptor release to the end of smb2_open error handling. Because no exact affected product list or fixed package versions were provided, use the kernel vendor or distribution advisory for the deployed platform to identify the corrected kernel build. Prioritize systems that run ksmbd and expose SMB over untrusted or broadly reachable networks. If immediate patching is not possible, reduce exposure by disabling ksmbd where it is not required, replacing it temporarily with a patched userspace SMB service if appropriate, restricting TCP/445 access to trusted clients, blocking external SMB access at network boundaries, and limiting SMB authentication to authorized users. Reboot into the patched kernel after installation; merely installing kernel packages without rebooting will not remediate a running vulnerable kernel.

How to confirm the fix worked

Confirm whether ksmbd is in use by checking for the ksmbd kernel module, ksmbd service/process activity, and listeners on TCP/445. Validate remediation by confirming the running kernel version, not only the installed kernel package version, matches a vendor build containing the fix. Check distribution changelogs or kernel source patches for the ksmbd durable reconnect use-after-free fix in smb2_open. After patching and rebooting, verify that SMB file sharing still works, durable reconnect behavior does not trigger kernel warnings, and kernel logs are free of new ksmbd-related oops, KASAN, use-after-free, or general protection fault messages. Exposure validation should include network scanning for SMB listeners and configuration review to confirm ksmbd is disabled or access-controlled where patching is delayed.

Typical attack path

1. Identify Linux hosts exposing SMB services, especially TCP port 445, and determine whether the service is ksmbd rather than Samba userspace smbd.
2. Authenticate or otherwise interact with the SMB service as required by the server configuration.
3. Create SMB2 file opens using durable handle capabilities.
4. Trigger a durable reconnect workflow against an existing durable file handle.
5. Manipulate timing, disconnect/reconnect behavior, or error conditions so the reconnect path reaches cleanup or response-pinning failure after the durable file descriptor reference has been released.
6. Cause ksmbd or the kernel to access the freed file descriptor object, leading to memory corruption symptoms such as a kernel oops, panic, or file service interruption.

How to detect it

To assess possible prior exploitation, review kernel logs, system journals, crash dumps, and SMB service telemetry for ksmbd crashes or memory-safety warnings around SMB2 open and durable reconnect activity. Useful log sources include journald, dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, kernel crash dump facilities such as kdump/vmcore, endpoint telemetry, and network logs for TCP/445. Look for kernel oopses, panics, KASAN reports, general protection faults, or slab-use-after-free messages referencing ksmbd, smb2_open, durable reconnect, durable file descriptors, or ksmbd worker threads. Correlate crash times with inbound SMB connections, reconnect storms, authentication events, file-open requests, or unusual client disconnect/reconnect behavior. Because no public exploit indicators or actor-specific tradecraft are provided, detection should focus on behavioral evidence of triggering the vulnerable code path and resulting kernel instability rather than fixed signatures of a known tool.

• KASAN: use-after-free
• BUG: KASAN: use-after-free in smb2_open
• use-after-free in smb2_open
• ksmbd: smb2_open
• ksmbd_put_durable_fd
• ksmbd_iov_pin_rsp
• durable reconnect
• durable file descriptor
• general protection fault
• kernel BUG at
• Oops:
• Kernel panic
• ksmbd:
• ksmbd.mountd
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• dmesg
• tcp/445

What your security team should do

• Inventory Linux systems exposing SMB on TCP/445 and determine whether they use in-kernel ksmbd.
• Patch ksmbd-enabled systems to a vendor kernel version containing the fix, then reboot to activate the corrected kernel.
• Prioritize externally reachable SMB servers, file servers with broad user access, and systems supporting critical business workflows.
• If patching is delayed, restrict SMB access to trusted networks and users, and disable ksmbd where it is not required.
• Monitor kernel logs for ksmbd-related crashes, KASAN use-after-free reports, oopses, panics, and repeated SMB durable reconnect errors.
• Treat unexplained ksmbd-triggered kernel crashes as potential exploitation attempts until ruled out, even though current exploit maturity and EPSS are low.
• Review firewall and segmentation policy to ensure SMB is not exposed to the internet or untrusted network zones.