CVE-2026-64394

What it actually does

This is an authorization bypass in the Linux kernel ksmbd SMB server. A remote authenticated SMB client can open a file handle with insufficient rights, such as FILE_WRITE_ATTRIBUTES without FILE_WRITE_DAC or FILE_WRITE_OWNER, and then issue an SMB2 SET_INFO request with InfoType SMB2_O_INFO_SECURITY to alter the file security descriptor. Because the vulnerable code path does not enforce the required per-handle access check, the client can rewrite file ownership, group, POSIX mode bits, POSIX ACLs, and Windows security descriptor xattrs. The practical result is unauthorized modification of access controls, which can lead to privilege escalation over SMB-shared files, unauthorized read/write access, data tampering, and possible denial of access to legitimate users.

Why it matters to the business

Organizations exposing Linux ksmbd SMB shares may face unauthorized changes to file permissions and ownership by users who already have limited SMB access. This can allow a low-privileged account to grant itself access to sensitive shared files, modify or delete business data, lock other users out, or stage further compromise through tampered scripts, documents, backups, or application files hosted on SMB shares. The CVSS score is high, but current EPSS is low and there is no known CISA KEV listing or public exploit maturity reported, so remediation should be prioritized based on whether ksmbd is enabled, exposed to untrusted networks, or used for sensitive file shares.

How an attack unfolds

An attacker first obtains valid SMB credentials for a share served by the Linux kernel ksmbd service. The attacker opens a target file or directory using a handle that does not include the normal rights required to change ownership or discretionary access control, but does include lesser metadata rights such as FILE_WRITE_ATTRIBUTES. The attacker then sends an SMB2 SET_INFO request using the security information class. In vulnerable kernels, ksmbd processes the request without verifying that the handle has WRITE_DAC or WRITE_OWNER-equivalent access. The server then applies the attacker-supplied security descriptor or ACL changes to the underlying file, potentially rewriting POSIX ACLs, mode bits, owner/group metadata, and Windows security descriptor xattrs. After permissions are changed, the attacker reopens or accesses the file using the newly granted rights to read, modify, delete, or deny access to data they should not control.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the ksmbd fix adding WRITE_DAC/WRITE_OWNER validation to SMB2 SET_INFO SECURITY handling. Because no exact fixed package versions were provided, use the relevant Linux distribution security advisory or upstream stable kernel release notes to identify the first fixed build for each deployed kernel stream. If immediate patching is not possible, disable ksmbd, unload or prevent loading the ksmbd module, or replace kernel SMB serving with a fully patched alternative where operationally feasible. Restrict SMB exposure to trusted networks, require strong authentication, remove unnecessary write or metadata permissions from shares, and avoid allowing low-trust users to write to sensitive shared locations. Review share configuration and filesystem ACLs after patching because permissions may already have been altered before remediation.

How to confirm the fix worked

Confirm whether ksmbd is in use by checking for the ksmbd kernel module, ksmbd processes/threads, listening SMB ports, and ksmbd configuration. Verify the running kernel package is at or above the vendor-fixed version once an advisory is available. Where safe, perform a controlled negative test using an account that can open a file with limited metadata rights but should not have WRITE_DAC or WRITE_OWNER permissions; an SMB2 SET_INFO SECURITY attempt should fail with access denied and should not alter ownership, mode bits, POSIX ACLs, or security descriptor xattrs. Also validate that the vulnerable system is not still booted into an older kernel after package installation. Review representative files on SMB shares to ensure owners, groups, ACLs, and security descriptor xattrs match expected baselines.

Typical attack path

1. Identify a Linux SMB service backed by ksmbd rather than Samba userspace smbd.
2. Authenticate to the SMB share with a low-privileged or compromised account.
3. Locate a file or directory where the account can obtain a handle with limited metadata permissions but should not be allowed to change ownership or ACLs.
4. Open the object without FILE_WRITE_DAC or FILE_WRITE_OWNER-equivalent rights.
5. Send an SMB2 SET_INFO request with InfoType SMB2_O_INFO_SECURITY containing a modified security descriptor or ACL.
6. Cause ksmbd to apply the unauthorized owner, mode, POSIX ACL, or Windows security descriptor xattr changes.
7. Reopen or access the object using the newly granted permissions.
8. Read, modify, delete, replace, or lock access to shared files depending on the permissions added.

How to detect it

To determine whether exploitation already occurred, focus on evidence of unauthorized permission and ownership changes on SMB shares served by ksmbd. Useful sources include SMB server logs if enabled, Linux auditd records for chmod/chown/setxattr/removexattr/acl changes, filesystem metadata timelines, extended attribute records, endpoint telemetry, network captures or Zeek/Suricata SMB logs, and identity logs showing which account accessed a share around the time of permission changes. Look for SMB2 SET_INFO requests using security information classes, especially from accounts that should not be delegated ownership or ACL-management rights. Correlate those events with changes to POSIX ACLs, mode bits, owner/group, or the Windows security descriptor xattr on shared files. Pay special attention to permission changes followed by successful reads, writes, deletes, renames, or executions by the same account. Because exploitation may not generate a unique kernel log entry by default, absence of ksmbd error messages does not rule out compromise; baseline comparison of share ACLs and filesystem metadata is often the most reliable approach.

• SMB2_SET_INFO
• SMB2_O_INFO_SECURITY
• InfoType=SMB2_0_INFO_SECURITY
• InfoType=SMB2_O_INFO_SECURITY
• SecurityInformation
• WRITE_DAC
• WRITE_OWNER
• system.nt_sec_desc
• setxattr
• removexattr
• set_posix_acl
• notify_change
• ksmbd
• ksmbd.mountd
• STATUS_ACCESS_DENIED
• chmod
• chown
• setfacl

What your security team should do

• Inventory Linux systems exposing SMB on TCP/445 and determine which use kernel ksmbd rather than Samba smbd.
• Prioritize patching internet-exposed, partner-accessible, multi-user, or sensitive-data SMB shares first.
• Apply the vendor-fixed kernel update and reboot into the fixed kernel; confirm the old kernel is no longer running.
• If patching is delayed, disable ksmbd or restrict SMB access to trusted network segments and VPN-only access.
• Audit SMB share permissions and filesystem ACLs for excessive write, attribute, ownership, or ACL-management rights.
• Review recent file owner, group, mode, POSIX ACL, and security descriptor xattr changes on ksmbd-served shares for suspicious permission expansion.
• Increase SMB and filesystem auditing for SET_INFO security operations and unexpected ACL or ownership changes.
• Monitor for low-privileged SMB accounts suddenly gaining access to files, directories, scripts, backups, or administrative shares they did not previously control.