Cloudanix VulnDB

CVE-2026-52944

None

CVSS

—

EPSS

0.1%

Published

Jun 24, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in some Linux file-sharing servers can let users change file settings even when they are supposed to have read-only access.

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

What it actually does

This vulnerability is an authorization bypass in the Linux kernel ksmbd SMB server implementation. The FSCTL_SET_SPARSE file-system control path allowed an SMB client to change a file’s sparse-file attribute without enforcing the share-level writable flag and without verifying that the opened file handle had FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES permissions. As a result, an authenticated SMB client with insufficient rights could alter file metadata on files it could open, including on read-only shares. The flaw does not directly provide code execution or privilege escalation, but it violates expected SMB access controls and can cause unauthorized file attribute changes.

Why it matters to the business

Organizations exposing Linux kernel ksmbd SMB shares could have file metadata modified by users or systems that should only have read access. The most likely operational impact is integrity loss: files may be marked sparse unexpectedly, potentially affecting backup behavior, storage accounting, file synchronization, compliance evidence, or application assumptions about file state. Because EPSS is low, the issue is not currently known to be broadly exploited, and it is not in the CISA Known Exploited Vulnerabilities catalog, but SMB services often protect shared business data, so unauthorized write-like behavior on read-only shares should still be treated as a meaningful access-control defect.

How an attack unfolds

An attacker first needs network access to an affected ksmbd SMB service and credentials or session access sufficient to open a target file. The attacker connects to a share that may be configured read-only, or opens a file with a handle that lacks write-data or write-attributes access. Instead of performing a normal write operation, the attacker sends an SMB2 IOCTL request using the FSCTL_SET_SPARSE control code against the open file handle. Vulnerable ksmbd versions process the request without checking whether the share is writable and without confirming the handle has the required write permissions. The kernel then changes the file’s sparse attribute and persists that metadata through extended attributes. A successful exploit leaves the attacker with unauthorized modification of file metadata, even though standard SMB permissions should have blocked the action.

How to fix it

Apply a Linux kernel update that includes the ksmbd fix adding both the share-level writable check and per-handle access check for FSCTL_SET_SPARSE. If vendor fixed package versions are not yet available in the advisory feed, obtain the latest security kernel update from the operating system or appliance vendor and confirm that the patch for ksmbd FSCTL_SET_SPARSE permission enforcement is included. Reboot into the patched kernel where required. As interim mitigation, disable ksmbd if it is not required, restrict SMB exposure to trusted networks, limit access to authenticated users with least privilege, and consider using an alternative SMB server implementation if operationally appropriate. For highly sensitive read-only shares, monitor for unexpected sparse-attribute changes until all affected systems are patched.

How to confirm the fix worked

Confirm exposure by checking whether systems run ksmbd rather than only user-space Samba, and whether the running kernel build includes the ksmbd FSCTL_SET_SPARSE permission-check fix. Validate remediation by testing from a non-privileged SMB account: open a file on a read-only share or with a handle lacking write attributes, then attempt FSCTL_SET_SPARSE. A fixed system should deny the operation with an access-denied or permission-related error and should not change the file’s sparse attribute or related extended attributes. Also verify the host has rebooted into the updated kernel, because installing a kernel package alone may not update the running kernel.

Typical attack path

  1. Identify a reachable Linux server exposing SMB shares through ksmbd.
  2. Authenticate to the SMB service or otherwise obtain access to open files on a share.
  3. Open a target file on a read-only share or with a handle lacking FILE_WRITE_DATA / FILE_WRITE_ATTRIBUTES rights.
  4. Send an SMB2 IOCTL request containing FSCTL_SET_SPARSE, control code 0x000900C4, for the opened file handle.
  5. Cause ksmbd to update the file’s sparse attribute despite insufficient permissions.
  6. Use the unauthorized metadata change to affect file integrity, storage behavior, backups, synchronization, or audit expectations.

How to detect it

Look for evidence of SMB clients issuing FSCTL_SET_SPARSE against files where the share or file handle should not have allowed write-like metadata changes. Useful sources include ksmbd debug logs if enabled, kernel logs, auditd records for extended-attribute changes, endpoint file-integrity monitoring, SMB network telemetry, packet captures, and storage or backup logs showing unexpected sparse-file transitions. Investigate sparse-attribute or DOS-attribute extended-attribute changes made through SMB sessions by accounts that only had read permissions. Because this vulnerability changes metadata rather than dropping a file or spawning a distinctive process, detection should focus on behavior: SMB2 IOCTL requests with control code 0x000900C4, changes to sparse-file attributes on read-only shares, and xattr updates occurring without corresponding authorized write access. If packet capture is available, filter for SMB2 IOCTL traffic to ksmbd servers and inspect requests using the FSCTL_SET_SPARSE control code. No public threat actor exploitation is currently identified from the provided data, so treat detections as suspicious misuse rather than confirmed campaign indicators.

  • FSCTL_SET_SPARSE
  • CtlCode=0x000900C4
  • 0x000900C4
  • c4000900
  • SMB2 IOCTL FSCTL_SET_SPARSE
  • FILE_ATTRIBUTE_SPARSE_FILE
  • user.DOSATTRIB
  • setxattr
  • fsetxattr
  • ksmbd

What your security team should do

  • Prioritize patching Linux systems that expose ksmbd SMB shares, especially internet-reachable systems, shared file servers, and systems hosting regulated or business-critical data.
  • Inventory SMB servers and distinguish ksmbd-based Linux kernel SMB services from Samba deployments, because this issue is specific to ksmbd.
  • Restrict SMB access to trusted network segments and block unnecessary inbound SMB traffic at firewalls and security groups.
  • Review read-only shares for unexpected metadata changes, especially sparse-file attribute changes after the vulnerability publication date.
  • Ensure SMB share permissions and file ACLs follow least privilege, and remove unnecessary read access to sensitive repositories.
  • Enable or increase SMB, kernel, auditd, and file-integrity logging for critical shares until patching is complete.
  • After patching, run a negative-permission test to confirm FSCTL_SET_SPARSE is denied on read-only shares and handles without write permissions.

The record

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.

Affected packages

Ecosystem Package Introduced Fixed