Cloudanix VulnDB

CVE-2026-64388

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Jul 25, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

Some Linux systems may fail to correctly change file owners on certain shared network drives, leaving people with access they were supposed to lose.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Data Tampering
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

This Linux kernel SMB client flaw causes ownership and group changes made with chown or chgrp on SMB3 POSIX Extension mounts to be silently ignored unless specific CIFS ACL-related mount modes are also enabled. As a result, local operations that appear to change file UID or GID on a remote SMB share may not actually update ownership on the server. The security impact is primarily an authorization and integrity failure: files can retain unintended owners or groups, potentially preserving access for users who should have lost it or preventing intended permission hardening from taking effect.

Why it matters to the business

Systems that rely on SMB-mounted storage for shared application data, user home directories, build artifacts, backups, or administrative workflows may incorrectly believe file ownership has been changed when it has not. This can lead to unauthorized access to sensitive files, incorrect segregation of duties, failed compliance assumptions around file ownership, and operational confusion during provisioning, deprovisioning, backup, or incident response activities. The vulnerability is not currently listed in CISA KEV, has very low EPSS, and has no known public exploit maturity, so urgency is lower than internet-facing remote-code-execution issues, but organizations using Linux SMB3 POSIX mounts should still remediate because the flaw can undermine file access controls.

How an attack unfolds

An attacker needs local access to a Linux system that mounts an SMB share using SMB3 POSIX Extensions in the affected configuration. The attacker identifies a workflow where an administrator, service, deployment process, or cleanup job changes ownership or group membership of files on the SMB-mounted path to restrict access or transfer control. Because the kernel client mishandles UID and GID updates in this mount mode, the ownership change may be reported as successful locally while not being applied correctly on the SMB server. The attacker then continues to access, modify, or influence files that should have been reassigned or protected, using the retained ownership or group state to bypass intended authorization controls.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the SMB client fix for SMB3 POSIX Extension ownership and group handling. No exact affected product or fixed package versions were provided, so remediation should be tracked through the relevant Linux distribution kernel advisories and upstream stable kernel updates. Where immediate patching is not possible, review SMB/CIFS mount options and avoid vulnerable SMB3 POSIX Extension configurations for security-sensitive paths. As a temporary mitigation, consider enabling CIFS ACL or mode-from-SID behavior where compatible with the environment, because the bug was triggered when SMB3 POSIX Extensions were used without those modes. For high-risk shares, avoid relying solely on client-side ownership changes until patched; validate ownership directly on the SMB server after administrative changes.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix by checking the installed kernel package version against the distribution advisory or by verifying the upstream SMB client patch is present. Enumerate CIFS/SMB mounts and review whether SMB3 POSIX Extensions are enabled and whether CIFS ACL or mode-from-SID options are absent. Perform a controlled validation on a non-production test file on an affected SMB mount: create a file, run chown and chgrp to change UID/GID, then confirm from the SMB server side or an independent client that the ownership and group actually changed. Repeat after patching or changing mount options. Also review automation that performs ownership changes on SMB-mounted paths and confirm it checks effective ownership rather than assuming command success is sufficient.

Typical attack path

  1. Gain local user access to a Linux host that mounts an SMB share using SMB3 POSIX Extensions.
  2. Identify SMB-mounted files or directories whose ownership or group is changed by administrative scripts, provisioning jobs, applications, or operators.
  3. Wait for or trigger a chown/chgrp operation intended to remove the attacker’s ownership, change group access, or harden permissions.
  4. Abuse the flaw where UID/GID updates are ignored by the SMB client in the affected mount configuration.
  5. Continue accessing or modifying files that should no longer be accessible under the intended ownership or group model.
  6. Use retained access to read sensitive data, tamper with shared files, disrupt workflows, or maintain unauthorized control over shared storage content.

How to detect it

This issue is difficult to detect as exploitation because it is a logic flaw in file ownership handling and may not produce explicit kernel, SMB server, or authentication errors. Focus on exposure identification and behavioral review. Collect mount information from /proc/mounts, findmnt, or endpoint configuration management to identify CIFS/SMB mounts using SMB3 POSIX Extensions without CIFS ACL or mode-from-SID options. Review Linux audit logs, shell history where appropriate, EDR telemetry, and process execution logs for chown, chgrp, fchown, lchown, or chownat activity targeting SMB-mounted paths. Compare those events with authoritative ownership state on the SMB server; suspicious evidence is a successful or apparently successful ownership/group change on the Linux client where the server-side UID/GID did not change. On SMB servers, review file metadata history, file access auditing, and access-control change logs for files that retained ownership or group access after administrative reassignment. Investigate cases where users continued reading or modifying files after deprovisioning, group removal, or ownership-transfer workflows should have revoked access. There are no known public exploit-specific indicators or named threat actors associated with this vulnerability at this time.

What your security team should do

  • Inventory Linux systems with CIFS/SMB mounts, prioritizing servers that use SMB-mounted shared data, home directories, application storage, backup locations, or build/deployment artifacts.
  • Identify mounts using SMB3 POSIX Extensions and determine whether they lack CIFS ACL or mode-from-SID options.
  • Patch affected Linux kernels through the relevant distribution security update channel as soon as practical, prioritizing systems where SMB ownership controls protect sensitive data.
  • Until patched, avoid performing security-sensitive chown/chgrp workflows on affected SMB mounts unless ownership is verified server-side after the operation.
  • Add validation checks to administrative scripts so ownership and group changes on SMB-mounted paths are confirmed after execution.
  • Review recent permission and ownership changes on SMB shares for unexpected retained ownership or group access.
  • Monitor for local users repeatedly invoking chown, chgrp, or related file-manipulation activity on SMB-mounted paths in contexts where they should not influence shared storage permissions.

The record

In the Linux kernel, the following vulnerability has been resolved: smb/client: fix chown/chgrp with SMB3 POSIX Extensions Ownership (chown) and group (chgrp) modifications were being ignored when mounting with SMB3 POSIX Extensions unless CIFS_MOUNT_CIFS_ACL or CIFS_MOUNT_MODE_FROM_SID were also explicitly set. Fix this by checking for posix_extensions in cifs_setattr_nounix() when updating UID and GID, ensuring that id_mode_to_cifs_acl() is called to map and set the ownership/group information on the server.

Affected packages

Ecosystem Package Introduced Fixed