Bug 2545023 (CVE-2026-104715)

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, file_mode, dir_mode, 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,file_mode=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 file_mode=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=TEST_SMB_PASSWORD
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 pam_mount
element in /etc/security/pam_mount.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,file_mode=0600,dir_mode=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,file_mode=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 file_mode=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 file_mode=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.