CVE-2026-104715: Cifs-utils: mount.cifs credential-file option injection allows local privilege boundary bypass

Jonathan reported a local privilege-boundary issue in mount.cifs. A non-privileged user can control a CIFS credentials file consumed by a privileged mount.cifs invocation, and the value from the credentials file is copied into the mount option string without validation. As a result, attacker-controlled mount options can be injected into the privileged mount.

The underlying problem is in the credentials-file parsing and option assembly path in cifs-utils: the parser reads the value of the username field, and the later CIFS option parser accepts mount options such as uid, filemode, dirmode, nosuid, and related flags. Because the credentials value is not filtered for separators such as commas and equals signs, a malicious value such as:

username=smbuser,uid=0,forceuid,noperm or username=smbuser,uid=0,forceuid,filemode=04755

is interpreted as additional CIFS mount options rather than as a literal username.

This issue is exploitable when a user-controlled credentials file is supplied to a privileged mount.cifs invocation. In the tested environment, the injected options caused the CIFS mount to be created with root-mapped ownership and client-side permission bypass, and in the stronger variant with filemode=04755 the mounted files were SUID-root-capable. Executing a file from the mounted share then resulted in the process obtaining effective UID 0 and running as a privileged process.

Reproduction steps:

1. Create an ordinary local user named cifsmanual, without sudo access. Create /home/cifsmanual/cifs-mount, owned by that user.

2. As cifsmanual, create /home/cifsmanual/.smbcredentials containing: username=smbuser password=TESTSMBPASSWORD Replace these with valid test credentials. Set the file mode to 0600 and keep it owned and writable by cifsmanual.

3. As administrator, configure a volume inside the existing pammount element in /etc/security/pammount.conf.xml with these attributes:

user: cifsmanual fstype: cifs server: server.example.test path: share mountpoint: /home/cifsmanual/cifs-mount

Set its options attribute to the following list: credentials=/home/cifsmanual/.smbcredentials,vers=3.0,nounix, nodev,forcegid,filemode=0600,dirmode=0700

Keep the packaged CIFS command template, which supplies the login user's UID/GID. Do not configure uid=0, forceuid, or noperm here.

4. On Debian/Ubuntu, run sudo pam-auth-update and enable "Mount volumes for user", retaining existing authentication profiles. Use a login service that invokes PAM, such as password-based SSH with UsePAM yes.

5. Login as cifsmanual and run these commands without sudo: id findmnt -rn -M "$HOME/cifs-mount" -t cifs -o SOURCE,TARGET,FSTYPE,OPTIONS && testfile=$(mktemp "$HOME/cifs-mount/probe.XXXXXX") && stat -c '%n uid=%u gid=%g mode=%a' "$HOME/cifs-mount" "$testfile"

Confirm the share is mounted, ownership matches the user's nonzero UID, and file creation succeeds. There must be no noperm option. This is baseline.

6. As the ordinary user, change only the credentials username line: username=smbuser,uid=0,forceuid,noperm,filemode=04755 Keep the valid username before the comma and the password unchanged.

7. Log out of all cifsmanual sessions and confirm the mount is gone.

8. Log in again and repeat step 5 without sudo. Expected: the process UID remains nonzero, but the mount contains uid=0,forceuid,noperm. The directory shows UID 0 and filemode=04755. File creation succeeds with UID 0 and mode 04755.

Impact:

9.1) This allows an unprivileged user to override mount behavior and force root-mapped ownership / client-side permission bypass on the mounted CIFS share. In the tested configuration, this can result in root-owned file creation and root-equivalent file semantics on the local mount.

9.2) Unprivileged users can inject filemode=04755 through the same credentials-file username field. The kernel CIFS parser accepts 04755 and sets the SUID bit on every file on the mount. Combined with uid=0,forceuid, every file becomes SUID-root. An attacker can place a binary on the share via SMB, execute it locally, and setuid(0) succeeds, yielding a process running in privileged shell, provided nosuid is not supplied on the mount.

9.3) Similarly, other potentially dangerous mount options can be exposed.

I have attached the draft patches that Paulo provided to fix this issue in cifs-utils(yet to be committed), it also addresses the case of 'USER' env along with the credential file.

Please evaluate this issue and let me know if you need additional information and share the next steps.

— Red Hat