CVE-2026-64399

What it actually does

The flaw is an authorization bypass in the Linux kernel ksmbd SMB server implementation. The SMB2 IOCTL handler for FSCTL_DUPLICATE_EXTENTS_TO_FILE calls vfs_clone_file_range() without enforcing the same share-level write permission and per-handle FILE_WRITE_DATA checks used by other write-capable operations. As a result, a remote SMB client can cause data extents from one file to be cloned over another file even when the destination is on a read-only share or the destination handle was not opened with data-write permission. This can allow unauthorized file modification, data corruption, and potentially broader compromise if overwritten files influence application behavior, authentication, configuration, or system operation.

Why it matters to the business

Organizations exposing Linux ksmbd file shares may have files modified or corrupted by clients that should only have read or metadata-level access. The operational risk is highest for shared repositories, configuration shares, application data directories, backups, and file exchange locations where integrity is critical. Although this vulnerability is not currently listed in CISA KEV and has low EPSS with no known public exploit maturity, the CVSS severity is critical because exploitation is network-reachable, low-complexity, and can directly undermine file integrity and availability.

How an attack unfolds

An attacker first reaches an SMB service backed by the Linux kernel ksmbd server. The attacker authenticates if the share requires credentials, or connects anonymously if guest access is enabled. They then identify a share or file path where their account should not be able to write file contents, such as a read-only share or a destination file opened with only FILE_WRITE_ATTRIBUTES. The attacker opens a source file and a destination file and sends an SMB2 IOCTL request using FSCTL_DUPLICATE_EXTENTS_TO_FILE. Because the vulnerable kernel path does not verify that the tree connection is writable and does not require FILE_WRITE_DATA on the destination handle, ksmbd passes the request to vfs_clone_file_range(), which clones the selected source extents over the destination file. The result is unauthorized overwriting of destination file data, enabling tampering, destructive corruption, or staged manipulation of files consumed by users or applications.

How to fix it

Upgrade to a Linux kernel version that includes the ksmbd permission-check fix for FSCTL_DUPLICATE_EXTENTS_TO_FILE. Because no exact fixed package versions were provided, use the kernel advisories from the operating system or distribution vendor and confirm that the patch adds both the share writability check and the destination handle FILE_WRITE_DATA requirement for this ioctl path. If immediate patching is not possible, disable ksmbd, use a user-space SMB server with appropriate hardening where feasible, restrict SMB access to trusted networks and authenticated users, remove guest access, and avoid exposing sensitive files through ksmbd read-only shares until patched. Treat read-only SMB permissions as unreliable for integrity protection on affected kernels.

How to confirm the fix worked

Confirm the running kernel includes the patched ksmbd code path. Administrators can validate by checking the installed kernel package changelog or source for permission enforcement in smb2_ioctl() for FSCTL_DUPLICATE_EXTENTS_TO_FILE, specifically checks equivalent to KSMBD_TREE_CONN_FLAG_WRITABLE and FILE_WRITE_DATA on the destination file handle. Operationally, test from a non-privileged SMB client account against a read-only ksmbd share: attempts to duplicate extents into a destination file should fail with an access-denied style SMB error and must not alter file content. Also verify that ksmbd is not loaded or listening if the service is intended to be disabled.

Typical attack path

1. Identify an exposed SMB service running Linux ksmbd.
2. Authenticate with any available SMB account, or use guest access if enabled.
3. Enumerate shares and locate files where the attacker has read-only or metadata-only access.
4. Open a source file and a destination file through SMB2.
5. Issue an SMB2 IOCTL request with FSCTL_DUPLICATE_EXTENTS_TO_FILE, control code 0x00098344.
6. Specify source and destination offsets and lengths so source extents are cloned over the destination file.
7. Verify that the destination file content changed despite the share or handle lacking normal data-write permission.
8. Use the unauthorized overwrite to corrupt data, alter application inputs, replace trusted content, or disrupt operations.

How to detect it

Detection should focus on evidence of unauthorized file modification through ksmbd and unusual SMB2 IOCTL activity. Review SMB server logs, system logs, auditd records, endpoint file integrity monitoring, and network captures for SMB2 IOCTL requests using FSCTL_DUPLICATE_EXTENTS_TO_FILE, especially against read-only shares or by users whose access should not include file-content writes. Standard ksmbd logging may not record the specific ioctl by default, so network telemetry or packet capture may be required to identify control code 0x00098344. On hosts, compare file modification times, hashes, and audit records for destination files against expected write permissions. Look for files changed by SMB users that only have read-only share access or metadata-only permissions. Because no named threat actors or public exploit maturity are provided, prioritize anomaly-based hunting over actor-specific indicators.

• FSCTL_DUPLICATE_EXTENTS_TO_FILE
• 0x00098344
• CtlCode: 0x00098344
• ctl_code=0x00098344
• SMB2 IOCTL FSCTL_DUPLICATE_EXTENTS_TO_FILE
• smb2_ioctl
• vfs_clone_file_range
• KSMBD_TREE_CONN_FLAG_WRITABLE
• FILE_WRITE_ATTRIBUTES
• FILE_WRITE_DATA
• ksmbd

What your security team should do

• Prioritize patching Linux systems that run ksmbd and expose SMB shares, especially internet-facing, partner-facing, guest-enabled, or broadly accessible file servers.
• Inventory ksmbd usage separately from Samba; this issue affects the in-kernel ksmbd server path, not every Linux SMB deployment.
• Restrict TCP/445 access to trusted networks and require authentication; remove guest access wherever possible.
• Temporarily disable ksmbd on systems where patching cannot be completed promptly and file integrity is important.
• Review permissions on read-only shares and sensitive directories, but do not rely on SMB read-only settings as a complete mitigation until the kernel is fixed.
• Enable or increase SMB audit logging where available and retain network telemetry for SMB2 IOCTL activity.
• After patching, perform a negative-access test to ensure FSCTL_DUPLICATE_EXTENTS_TO_FILE cannot modify files without FILE_WRITE_DATA permission.
• Hunt for unexpected file content changes on ksmbd-backed shares, especially files modified by accounts that should not have data-write rights.