Cloudanix VulnDB

CVE-2026-64398

High · 8.1

CVSS

8.1

EPSS

0.5%

Published

Jul 25, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A logged-in user with limited access to a Linux file share may be able to erase parts of shared files they should not be allowed to change.

Exploitation
Remote Authenticated
Attacker needs
Low Privilege
Complexity
Low
Impact
Data Tampering
Component
OS kernel
Class
Authorization Bypass
Remediation
Patch
Effort
Medium
Patch risk
Medium

What it actually does

CVE-2026-64398 is an authorization bypass in the Linux kernel ksmbd SMB server implementation. The SMB2 ioctl handler for FSCTL_SET_ZERO_DATA allowed an authenticated SMB client to zero ranges of file content when the share was writable, but it failed to verify that the specific file handle had FILE_WRITE_DATA permission. Because handles opened with FILE_WRITE_ATTRIBUTES could still result in a writable kernel file object, the lower-level vfs_fallocate() permission check did not prevent data modification. The practical effect is unauthorized destruction or corruption of file data over SMB by a user who has limited write-attribute privileges but should not be allowed to modify file contents.

Why it matters to the business

Organizations using Linux ksmbd to provide SMB file shares may be exposed to unauthorized file tampering or data destruction by authenticated users or compromised low-privilege accounts. The most likely operational consequence is corruption or loss of shared files, which can disrupt business workflows, damage data integrity, and require restoration from backups. The CVSS score is high at 8.1 because exploitation is network-accessible, low-complexity, requires no user interaction, and can significantly affect integrity and availability. The EPSS score is currently low and the vulnerability is not listed in CISA KEV, but the issue is recently published and affects a common file-sharing protocol, so exposed ksmbd deployments should still be prioritized for patching.

How an attack unfolds

An attacker first needs valid SMB authentication to a Linux system running ksmbd and access to a writable share. Instead of opening a file with normal file-content write permissions, the attacker opens a target file with limited access such as FILE_WRITE_ATTRIBUTES. Due to the kernel authorization flaw, this handle can still be associated with an FMODE_WRITE file object. The attacker then sends an SMB2 IOCTL request using FSCTL_SET_ZERO_DATA and specifies a byte range in the file. ksmbd checks that the share is writable but does not enforce that the handle grants FILE_WRITE_DATA. The request reaches ksmbd_vfs_zero_data(), which invokes vfs_fallocate() with hole-punching or zero-range behavior, causing the selected file range to be zeroed despite the caller lacking proper content-write rights. Repeating the operation can corrupt or destroy files accessible through the share.

How to fix it

Upgrade to a Linux kernel version that includes the ksmbd fix requiring FILE_WRITE_DATA permission for FSCTL_SET_ZERO_DATA. If vendor kernel packages are used, apply the latest security update from the operating system or appliance vendor rather than relying only on upstream version numbers. Where immediate patching is not possible, reduce exposure by disabling ksmbd if it is not required, replacing it temporarily with a patched Samba userspace SMB service where appropriate, restricting SMB access to trusted networks and VPNs, and tightening share and filesystem permissions so low-privilege accounts cannot open sensitive files with unnecessary write-related rights. Ensure reliable backups are available and protected from modification through SMB.

How to confirm the fix worked

Confirm the running kernel includes the ksmbd patch that adds a FILE_WRITE_DATA permission check before processing FSCTL_SET_ZERO_DATA. Validate package status using the operating system vendor’s advisory tooling and confirm the host has rebooted into the updated kernel. Exposure can be checked by determining whether the ksmbd module is loaded or the ksmbd service is active and whether TCP/445 is reachable from untrusted or broad internal networks. Functional validation can be performed in a controlled test environment by attempting FSCTL_SET_ZERO_DATA using an authenticated SMB handle opened with FILE_WRITE_ATTRIBUTES but without FILE_WRITE_DATA; a fixed system should deny the operation and file contents should remain unchanged.

Typical attack path

  1. Obtain or compromise valid SMB credentials for a user with access to a ksmbd-hosted share.
  2. Identify a writable SMB share and files where the account can open handles with limited write attributes but should not have file-content write permission.
  3. Open a target file over SMB with FILE_WRITE_ATTRIBUTES or another insufficient access mask that should not allow data modification.
  4. Send an SMB2 IOCTL request using FSCTL_SET_ZERO_DATA with attacker-chosen file offsets and lengths.
  5. Exploit the missing per-handle FILE_WRITE_DATA permission check to invoke zeroing through ksmbd_vfs_zero_data() and vfs_fallocate().
  6. Repeat against additional file ranges or files to corrupt data, cause application errors, or trigger operational disruption.

How to detect it

To assess prior exploitation, focus on SMB server logs, Linux audit logs, kernel logs, file integrity monitoring, and storage or backup telemetry for evidence of unexpected file zeroing or hole-punching activity. ksmbd may not log every FSCTL_SET_ZERO_DATA request by default, so network telemetry capable of parsing SMB2 IOCTL traffic is especially useful. Look for authenticated SMB clients issuing FSCTL_SET_ZERO_DATA against files where the same user does not normally perform content writes, followed by sudden file corruption, large sparse regions, zero-filled byte ranges, or abnormal backup change volume. Correlate SMB session information on TCP/445 with file modification timestamps, auditd records for truncate/fallocate-like operations where available, and application errors caused by corrupted shared files. Investigate low-privilege or recently compromised accounts that accessed many files, opened files with write-attribute-style permissions, or generated unusual SMB IOCTL patterns. Because the vulnerability is not currently known to be exploited in KEV and no public exploit maturity is reported, absence of these artifacts does not prove absence of exploitation.

  • SMB2 IOCTL FSCTL_SET_ZERO_DATA
  • FSCTL_SET_ZERO_DATA
  • ctl_code=0x000980c8
  • 0x000980c8
  • ksmbd
  • ksmbd.mountd
  • tcp/445
  • KSMBD_TREE_CONN_FLAG_WRITABLE
  • ksmbd_vfs_zero_data
  • vfs_fallocate
  • FALLOC_FL_PUNCH_HOLE
  • FALLOC_FL_ZERO_RANGE
  • FILE_WRITE_ATTRIBUTES
  • FILE_WRITE_DATA

What your security team should do

  • Inventory Linux systems providing SMB shares via ksmbd and determine whether they are running a vulnerable kernel.
  • Prioritize patching ksmbd-enabled systems, especially those exposing TCP/445 to broad internal networks, untrusted users, or internet-adjacent segments.
  • Apply vendor kernel security updates and reboot into the fixed kernel; verify the active kernel version after reboot.
  • Temporarily disable ksmbd or restrict SMB access with host firewalls, network ACLs, VPN requirements, and segmentation if patching is delayed.
  • Review SMB share permissions and remove unnecessary write-attribute or write-capable access from low-privilege accounts.
  • Monitor for suspicious SMB2 IOCTL activity involving FSCTL_SET_ZERO_DATA, especially from accounts that do not normally modify file contents.
  • Review file integrity alerts, backup deltas, and unusual zero-filled file regions on critical shares for signs of prior abuse.
  • Ensure backups of SMB-hosted data are recent, immutable or offline, and tested for restoration.

The record

In the Linux kernel, the following vulnerability has been resolved: ksmbd: add a permission check for FSCTL_SET_ZERO_DATA FSCTL_SET_ZERO_DATA in smb2_ioctl() destroys file data via ksmbd_vfs_zero_data() -> vfs_fallocate(PUNCH_HOLE/ZERO_RANGE) after checking only the share-level KSMBD_TREE_CONN_FLAG_WRITABLE, with no per-handle access check. A handle opened with only FILE_WRITE_ATTRIBUTES still yields an FMODE_WRITE filp (FILE_WRITE_ATTRIBUTES is part of FILE_WRITE_DESIRE_ACCESS_LE, so smb2_create_open_flags() opens it O_WRONLY), so the vfs_fallocate FMODE_WRITE check does not stop it; only the missing fp->daccess gate would. Reproduced on mainline 7.1-rc7 with KASAN by an authenticated SMB client: a FILE_WRITE_ATTRIBUTES-only handle zeroed 4096 bytes of file data it had no FILE_WRITE_DATA right to (6/6; a FILE_READ_DATA-only handle was correctly denied). This is the unfixed sibling of commit cc57232cae23 ("ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE"). Because SET_ZERO_DATA writes data (not an attribute), require FILE_WRITE_DATA.

Affected packages

Ecosystem Package Introduced Fixed