CVE-2026-64392

What it actually does

This flaw affects the Linux kernel ksmbd SMB server implementation. When an SMB client opens a file with delete-on-close semantics, the actual deletion may occur later during deferred close or durable handle teardown, when no original request context is active. In vulnerable kernels, ksmbd performs the file unlink or alternate data stream xattr removal using ksmbd worker credentials instead of the credentials of the authenticated user who opened the handle. That can bypass filesystem authorization checks, allowing a remote SMB user to delete files or SMB alternate data stream metadata that their own fsuid, fsgid, groups, or capability restrictions should not permit them to remove. The primary impacts are unauthorized data modification and denial of service through deletion of accessible-but-not-deletable content.

Why it matters to the business

An attacker with access to an affected ksmbd file share may be able to delete shared files or metadata despite lacking proper permissions, which can disrupt operations, corrupt shared data, break applications that rely on SMB-hosted files, and cause recovery costs from backups. The CVSS score is critical at 9.1 because exploitation is network-reachable, low-complexity, and can cause high integrity and availability impact. However, it is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS at 0.00469, and has no public exploit maturity indicated, so prioritization should focus first on internet-exposed ksmbd services, broadly accessible internal SMB shares, multi-user file servers, and systems hosting critical operational data.

How an attack unfolds

An attacker first identifies a Linux host exposing SMB service through ksmbd and obtains access to a share, either through valid credentials, guest access, or another authentication path allowed by the service. The attacker then opens a target file or SMB alternate data stream in a way that causes delete-on-close to be recorded on the handle, targeting content the attacker can reach but should not be allowed to delete under normal filesystem permissions. Instead of closing the handle in a normal request path, the attacker can trigger a deferred or durable handle teardown, such as by disconnecting or allowing the durable handle cleanup path to run. On vulnerable kernels, ksmbd completes the delete operation using worker credentials rather than the opener's credentials, so the filesystem permission check can be evaluated under an unintended authority. If successful, the target file is unlinked or ADS-related xattr data is removed, causing unauthorized data loss or metadata corruption.

How to fix it

Upgrade to a Linux kernel version that includes the ksmbd fix for using the opener's captured credentials during delete-on-close processing. Because the input does not provide exact fixed kernel versions, use the fixed kernel packages supplied by the operating system or distribution vendor for this CVE and reboot into the patched kernel. If immediate patching is not possible, reduce exposure by disabling ksmbd where it is not required, replacing it temporarily with a patched user-space SMB implementation if appropriate, restricting SMB access to trusted networks, disabling guest or anonymous share access, tightening share and filesystem permissions, and ensuring backups are current and protected from SMB write/delete access. Systems with SMB exposed to untrusted networks or hosting critical shared data should be remediated first.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix, not merely that an updated package is installed; verify after reboot with kernel package inventory and uname output. Confirm whether ksmbd is enabled by checking for the ksmbd kernel module/service, active SMB listeners on TCP 445, and configured ksmbd shares. Review vendor advisories for the exact fixed package version applicable to the distribution. Where safe, perform a controlled permission test on a non-production share: use an account that can open or read a test file but lacks delete permission, attempt SMB delete-on-close behavior, and verify the file cannot be removed after disconnect or durable handle cleanup. Also validate that compensating controls are in place if patching is deferred, including network ACLs, firewall rules, disabled guest access, and immutable/offline backups.

Typical attack path

1. Discover a Linux server exposing SMB shares backed by the kernel ksmbd service.
2. Authenticate to the SMB service or use guest access if enabled.
3. Enumerate shares and identify files or alternate data streams that are reachable but should not be deletable by the attacker.
4. Open a target object with delete-on-close semantics or equivalent SMB create disposition/options.
5. Trigger deferred close or durable handle teardown so final cleanup happens outside the original request context.
6. Vulnerable ksmbd performs the unlink or ADS xattr removal using worker credentials instead of the opener's credentials.
7. Confirm unauthorized deletion or metadata removal and repeat against additional files to cause disruption or data loss.

How to detect it

There are no public malware artifacts or unique exploitation strings known for this issue, so detection should focus on behavioral evidence of unauthorized SMB deletions. Review ksmbd service logs, kernel logs, system audit logs, filesystem audit tooling, EDR file-deletion telemetry, backup/versioning logs, and SMB network telemetry for delete operations followed by disconnects, durable handle cleanup, or session teardown by accounts that normally lack delete rights. On Linux file servers, enable or query auditd/fanotify/inotify-based monitoring for unlink, unlinkat, rename, removexattr, lremovexattr, and fremovexattr events on SMB-exported directories, then correlate events to ksmbd activity, source IPs, SMB usernames, and session timing. Look for bursts of deletions, deletions by guest or low-privilege users, deletion of files owned by other users, removal of extended attributes associated with SMB alternate data streams, and discrepancies where filesystem permissions should have denied deletion. Network defenders with SMB inspection can hunt for SMB2 create requests using delete-on-close semantics followed by abnormal disconnects or durable handle reconnect/cleanup behavior. Because successful exploitation may look like ordinary file deletion at the filesystem layer, correlation with authorization expectations and user behavior baselines is essential.

What your security team should do

• Inventory Linux systems running ksmbd and prioritize those exposing TCP 445 to untrusted networks or large internal user populations.
• Apply vendor kernel updates containing the ksmbd delete-on-close credential fix and reboot into the patched kernel.
• Temporarily restrict SMB access to trusted subnets or VPN-only paths until patching is complete.
• Disable ksmbd on systems where SMB service is not required.
• Review ksmbd share configurations for guest access, broad write access, and mismatches between share permissions and underlying filesystem permissions.
• Increase monitoring for unusual delete activity over SMB, especially deletes performed by low-privilege, guest, or service accounts.
• Verify backups for SMB-hosted data are recent, restorable, and protected from modification through SMB.
• For critical file servers, run a focused hunt for unexpected file deletions or ADS/xattr removals around the period before patching.
• Track vendor advisories because fixed package versions may vary by distribution and kernel branch.