[BUG 2/3] smb: client: server-provided symlinks can escape mount confinement

Resending in plain text because the original copy was rejected by linux-cifs due to Outlook always wanting talk html; apologies for the duplicate to direct recipients...

Hello Steve, Paulo, and linux-cifs maintainers,

My name is Daniel Birtwhistle. In my role, I assess security properties of
software inherited by GE HealthCare products. I am writing personally as the
researcher and technical contact.

This is the second of three coordinated CIFS client reports. The first covers
SMB2/3 response-signature failures being logged but not enforced, and the third
covers client-required sealing being dropped after reconnect. This message
covers the independently fixable mount-confinement behavior and can be
classified separately.

I am reporting security-relevant mount-confinement behavior and asking for the
maintainers' classification. I am not requesting a CVE or asserting a final
severity. Local resolution of UNIX-client symlinks is longstanding behavior,
was described publicly by Samba in connection with CVE-2010-0926, and was
deliberately preserved for existing users by 3363da82e02f. The narrower concern
is that a modern ordinary share writer can trigger local traversal even on a
signed, encrypted, noposix SMB3.1.1 mount, with no selective CIFS option to
confine links while preserving safe in-share links.

Observed behavior

A server-provided absolute symlink target, or a relative target with enough
".." components, is returned by cifs_get_link() and resolved by the VFS in the
accessing process's local root rather than inside the SMB mount.

I reproduced the common sink through:

- STATUS_STOPPED_ON_SYMLINK with an absolute target;
- STATUS_STOPPED_ON_SYMLINK with an upward relative target; and
- FSCTL_GET_REPARSE_POINT with IO_REPARSE_TAG_NFS/NFS_SPECFILE_LNK.

Versions and practical path

- The full three-trigger read/write matrix ran on mainline
  94515f3a7d4256a5062176b7d6ed0471938cd51a and reproduced on Ubuntu
  6.8.0-117-generic.
- Upstream 980ab36ae5972c83f683b939e50c469c4947229e from 2026-07-19
  retains the same cifs_get_link() sink at fs/smb/client/cifsfs.c:1272-1297.
- The stopped-on-symlink path dates at least to b42bf88828cd (v3.12); the NFS
  reparse path dates at least to d5ecebc4900d (v5.3).

In a separate SMB3.1.1 check on Kali 6.18.12, an ordinary authenticated
write-capable Samba user created a native absolute link and a fresh Linux
client mounted with mandatory signing, AES-128-GCM encryption, and noposix
followed it against its own process root. This does not exceed that process's
permissions or namespace. It becomes security-relevant when a privileged
automated consumer follows attacker-modifiable share paths, which is the same
general risk as following untrusted local symlinks.

Controls and existing mitigation

- Plain files and in-share relative links remained on the server.
- A chrooted accessor resolved against the chroot root, confirming that the
  accessor's namespace and credentials bound the effect.
- VFS MS_NOSYMFOLLOW blocked all tested paths, but also blocked legitimate
  in-share symlinks.
- reparse=none, symlink=none, and symlinkroot did not provide a general
  follow-time containment policy in the tested matrix.

Possible fix direction

I tested a cifs_get_link() guard that rejects absolute targets and relative
targets that climb above the mount while preserving lstat/readlink and
in-share relative links. The complete positive/negative matrix passed with
zero escapes. Because some users intentionally rely on local traversal, I
expect an explicit mount option or opt-in policy may be more compatible than
changing the default.

Would you classify the modern share-writer path as a client security-boundary
bug, or as expected symlink semantics needing an opt-in containment feature?
If the latter, would an option such as "confine server-provided symlinks to
this mount" be acceptable in the CIFS client, or should this be addressed
through generic nosymfollow/cifs-utils support and documentation? I have a
tested source harness, raw transcripts, and a candidate patch with the relevant
introduction commits. I have not posted the reproducer or attached it here,
but can provide it directly for review.

Requested credit, if useful: Daniel Birtwhistle



Best Regards,

Daniel Birtwhistle
Senior Director Product Security & Assessment