CVE-2026-64395

What it actually does

This is an authorization bypass in the Linux kernel SMB server, ksmbd. The SMB FSCTL_DUPLICATE_EXTENTS_TO_FILE operation allowed a client to request a server-side copy from a source file without verifying that the source file handle had FILE_READ_DATA permission. As a result, an attacker who could obtain a limited-access handle to a file, such as one opened only for attributes or metadata access, could cause ksmbd to copy the file’s contents into another file that the attacker can read. The primary impact is unauthorized disclosure of file contents over SMB; integrity and availability are not the main impacts.

Why it matters to the business

Organizations using the in-kernel Linux SMB server may have sensitive files exposed to users or network clients that should not be able to read them. This can lead to leakage of documents, credentials, backups, source code, configuration files, or regulated data stored on affected SMB shares. Although there is no known public exploit or CISA KEV listing at this time, the flaw is remotely reachable over SMB where ksmbd is exposed, has low attack complexity, and affects confidentiality, so internet-exposed or broadly accessible SMB services should be prioritized.

How an attack unfolds

An attacker first gains network access to an SMB service backed by the Linux kernel ksmbd server. The attacker identifies a file on a share where they can open the source file with limited access, such as attribute or metadata access, but are not authorized to read its contents. They also identify or create a destination file that they are allowed to read. The attacker then sends an SMB IOCTL request using FSCTL_DUPLICATE_EXTENTS_TO_FILE, instructing the server to duplicate data extents from the protected source file into the attacker-controlled or attacker-readable destination file. Because vulnerable ksmbd versions failed to require FILE_READ_DATA on the source handle before calling the underlying VFS copy or clone operation, the copy can succeed even though the attacker could not directly read the original file. The attacker then reads the destination file over SMB to recover the protected contents.

How to fix it

Apply the Linux kernel update that contains the ksmbd fix requiring FILE_READ_DATA on the source handle before FSCTL_DUPLICATE_EXTENTS_TO_FILE invokes vfs_clone_file_range() or vfs_copy_file_range(). Use the corrected kernel packages from the Linux distribution or appliance vendor; no universal fixed version was provided in the input, so validate against the vendor advisory or kernel changelog for this specific issue. If immediate patching is not possible, disable ksmbd where feasible, replace it with a fully patched SMB service, restrict SMB access to trusted networks and authenticated users, block TCP/445 from untrusted networks, and review share permissions so untrusted users cannot create attacker-readable destination files near sensitive data. These mitigations reduce exposure but do not fully correct the missing authorization check.

How to confirm the fix worked

Confirm that systems are not running a vulnerable ksmbd kernel build by checking the installed kernel package against the distribution or vendor advisory for this issue. Verify whether ksmbd is in use by checking for the ksmbd kernel module and SMB service exposure on TCP/445. Where safe and authorized, perform a negative authorization test: attempt FSCTL_DUPLICATE_EXTENTS_TO_FILE using a source handle that lacks FILE_READ_DATA and confirm that the server denies the operation rather than copying data. Also confirm that network controls prevent untrusted access to SMB and that sensitive shares do not allow unnecessary write or create permissions.

Typical attack path

1. Reach an SMB service implemented by Linux ksmbd over the network.
2. Authenticate or otherwise obtain access sufficient to browse or interact with an SMB share, depending on the share configuration.
3. Open a target source file with limited permissions that do not include FILE_READ_DATA but do allow a valid handle to be obtained.
4. Create or select a destination file in a location the attacker can read.
5. Send an SMB2 IOCTL request using FSCTL_DUPLICATE_EXTENTS_TO_FILE to copy data from the protected source handle to the readable destination handle.
6. Read the destination file and extract the copied sensitive data.

How to detect it

There is no single reliable host artifact that proves exploitation, because the abuse uses a legitimate SMB server-side copy operation and results in normal-looking destination files. Detection should correlate SMB protocol telemetry, ksmbd activity, and file audit logs. Look for SMB2 IOCTL requests with FSCTL_DUPLICATE_EXTENTS_TO_FILE, especially where the source file is in a sensitive path and the destination file is in a user-writable or attacker-readable location. If packet capture, Zeek, Suricata, or SMB-aware logging is available, search for the FSCTL_DUPLICATE_EXTENTS_TO_FILE control code 0x00098344. On hosts, collect auditd, eBPF, fanotify, or file integrity telemetry showing unexpected clone/copy behavior by ksmbd into writable share paths. Review destination files created or modified over SMB shortly before being read by the same client. Investigate cases where the source file was opened with metadata-only or attribute-like access followed by a duplicate-extents IOCTL and a read of the destination file. Standard Linux authentication logs may only show the SMB session and will not by themselves confirm the bypass.

• FSCTL_DUPLICATE_EXTENTS_TO_FILE
• 0x00098344
• SMB2 IOCTL
• CtlCode=0x00098344
• ksmbd
• ksmbd.mountd
• /sys/module/ksmbd
• /proc/fs/ksmbd
• duplicate_extents
• DUPLICATE_EXTENTS_TO_FILE

What your security team should do

• Inventory Linux systems exposing SMB on TCP/445 and determine which use kernel ksmbd rather than userspace Samba smbd.
• Prioritize patching internet-exposed, cross-network, or multi-user ksmbd servers that host sensitive files.
• Apply vendor kernel updates containing the ksmbd authorization fix; reboot if required for the patched kernel to take effect.
• If patching is delayed, disable ksmbd or restrict SMB access to trusted networks and users only.
• Review SMB share permissions to minimize cases where users can open sensitive files for metadata access and write attacker-readable destination files.
• Enable or increase SMB, file access, and network telemetry around SMB2 IOCTL activity, especially FSCTL_DUPLICATE_EXTENTS_TO_FILE.
• Hunt for unusual server-side copy activity from sensitive directories into user-writable or temporary share locations.
• Review recently created files in writable SMB shares for unexpected copies of sensitive content.