CVE-2026-64393

What it actually does

This is an authorization-bypass flaw in the Linux kernel ksmbd SMB server. SMB2 SET_INFO operations validate access against the SMB file handle, but subsequent path-based VFS operations were performed using the current ksmbd worker credentials rather than the credentials captured when the handle was opened. As a result, a remote SMB client may be able to perform metadata or path-changing operations that should have been rejected by normal Linux ownership, inode permission, or LSM policy checks. The primary impacts are unauthorized integrity changes and potential availability disruption to files exposed through ksmbd-backed SMB shares.

Why it matters to the business

Organizations using the in-kernel ksmbd SMB server could face unauthorized modification, deletion, renaming, permission changes, or other disruptive changes to shared files. This can affect file share reliability, business data integrity, application workflows that depend on SMB storage, and recovery operations if critical shared content is altered. The CVSS score is critical, but current public exploitation signals are low: EPSS is 0.00479, it is not listed in CISA KEV, no ransomware use is indicated, and exploit maturity is reported as none 16 days after publication. Internet- or broadly network-accessible SMB services should still be prioritized because exploitation is network-reachable and low-complexity if ksmbd is enabled.

How an attack unfolds

An attacker first identifies a system exposing SMB through the Linux kernel ksmbd service, typically on TCP port 445. The attacker establishes an SMB session and obtains or uses a file handle with a set of granted access rights. They then issue crafted SMB2 SET_INFO requests against files, directories, or security metadata exposed by the share. Due to the vulnerable credential handling, ksmbd performs later path-based VFS permission checks using the ksmbd worker context rather than the opener credentials associated with the SMB handle. If the worker context is more privileged than the opener, Linux filesystem and LSM enforcement can be bypassed for the affected operation. The attacker can then cause unauthorized changes such as modifying file metadata, changing permissions, renaming or linking paths, or otherwise disrupting shared data, depending on share configuration and filesystem policy.

How to fix it

Apply the Linux kernel update from the relevant distribution or appliance vendor that includes the ksmbd fix titled "ksmbd: run set info with opener credentials." No exact fixed kernel versions were provided in the input, so remediation should be based on vendor security advisories and backport status rather than upstream version numbers alone. If immediate patching is not possible, reduce exposure by disabling ksmbd, unloading or preventing use of the ksmbd kernel module where feasible, blocking SMB access from untrusted networks, restricting TCP/445 to trusted clients, enforcing least-privilege SMB share permissions, and monitoring or temporarily disabling write access on sensitive shares. If SMB service is required and operationally acceptable, consider using a patched user-space SMB implementation instead of ksmbd until the kernel is updated.

How to confirm the fix worked

Confirm the host is actually using ksmbd and not only another SMB implementation. Validate the running kernel package includes the vendor backport for the ksmbd SET_INFO credential-scope fix, then reboot if required and verify the running kernel matches the patched package. Check loaded modules and service state for ksmbd, and confirm TCP/445 exposure is limited as intended. Where safe, perform an authorization regression test using a low-privileged SMB account: attempt SET_INFO-style operations such as renaming, metadata changes, permission changes, or ownership/security changes against files the account should not be allowed to modify, and confirm they are denied after patching. Review distribution changelogs or kernel commit metadata for the exact fix rather than relying only on version comparison, because enterprise kernels often backport fixes without changing to the newest upstream release.

Typical attack path

1. Discover an SMB service exposed by a Linux host running the in-kernel ksmbd server.
2. Connect to the SMB service over the network, commonly TCP/445.
3. Open a target file or directory through an SMB share and obtain an SMB handle.
4. Send SMB2 SET_INFO requests for file, path, or security information that trigger path-based VFS helpers.
5. Abuse the mismatch between opener credentials and ksmbd worker credentials to bypass intended ownership, inode permission, or LSM checks.
6. Modify, rename, relink, delete, or otherwise disrupt shared files or metadata within the limits of the vulnerable code path and share configuration.

How to detect it

There are no reliable public exploit-specific indicators for this vulnerability, and successful exploitation may look like ordinary SMB file-management activity unless detailed auditing is enabled. Focus detection on behavior: unexpected SMB-driven file renames, permission changes, ownership changes, link creation, deletion, timestamp changes, or security descriptor updates that should not be allowed for the apparent user. Useful log and telemetry sources include Linux auditd records for chmod, chown, rename, link, unlink, setxattr, removexattr, and related syscalls on SMB share paths; kernel or system logs for ksmbd activity or errors; network metadata showing SMB2 SET_INFO requests to ksmbd servers; EDR file modification telemetry; and file integrity monitoring on sensitive shares. Correlate changes with SMB client IP, authenticated SMB user, local UID/GID, and time of operation. Pay particular attention to bulk changes, low-privileged accounts causing privileged-looking metadata updates, modifications to access-control metadata, and SMB activity from new or unusual source hosts. Absence of these artifacts does not prove non-exploitation if auditing was not enabled before the event.

What your security team should do

• Identify Linux systems exposing SMB via ksmbd, especially systems reachable from untrusted networks or large internal network segments.
• Prioritize patching for ksmbd-enabled hosts that allow write access to SMB shares or host business-critical shared data.
• If patching cannot be completed quickly, restrict TCP/445 to trusted clients and disable ksmbd on systems where SMB service is not required.
• Review share permissions and remove unnecessary write, rename, delete, ownership, and permission-changing rights from low-trust users.
• Enable or increase audit coverage for SMB-backed file changes, including chmod, chown, rename, link, unlink, delete, and attribute modification events on sensitive shares.
• Hunt for unusual file metadata or path changes over SMB, especially changes performed by unexpected users, outside normal business hours, or at unusual volume.
• Track vendor advisories for exact fixed kernel package versions and confirm that installed and running kernels include the backported fix.
• Because this is not currently in CISA KEV and has low EPSS, prioritize based on exposure and data sensitivity, but do not defer remediation on externally reachable or high-value file servers.