[SECURITY] ksmbd: SMB CREATE widens inherited POSIX ACL masks

Hello KSMBD maintainers,

KSMBD widens an inherited POSIX ACL mask to rwx when an SMB client
creates a file or directory. A named user or group entry that an
administrator intentionally made ineffective with a restrictive mask
can therefore become effective on the new object. For a new directory,
KSMBD also installs the widened ACL as the default ACL, so the
exposure propagates to descendants.

Affected Versions

The vulnerable code is present in the initial in-tree KSMBD merge:

Commit: e24c567b7ecff1c8b6023a10d7f78256cef742c4 (Linux 5.15)

The issue remains present in Linux 7.2-rc3:

Commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa

I therefore assess the source-level affected range as Linux 5.15
through Linux 7.2-rc3.

I dynamically reproduced the issue on Linux 7.1.3:

Commit: 199c9959d3a9b53f346c221757fc7ac507fbac50

I did not dynamically test every intervening stable branch.

Required Conditions

CONFIG_FS_POSIX_ACL is enabled.
The backing filesystem supports POSIX ACLs.
A parent default ACL contains a named user or group entry that grants
broader permissions than the ACL mask permits.
An authenticated SMB principal creates a new object beneath that parent.
A second principal maps to the named ACL identity.

Observed Impact

In an owned disposable VM, I used two distinct SMB and Unix principals.

The parent default ACL granted the secondary principal rwx but used
mask::---, making that named entry intentionally ineffective. A
locally created VFS child preserved mask::--- and correctly denied the
secondary principal read and write access.

A child created through SMB instead received mask::rwx. The secondary
principal successfully read the creator's canary and overwrote the
file. An SMB-created directory likewise received widened access and
default ACLs, allowing a grandchild created beneath it to inherit the
widened permissions. The widened ACL state persisted across reboot.

This is a persistent cross-principal confidentiality and integrity
failure affecting newly created SMB objects.

I am not claiming:

Access to pre-existing objects.
Code execution.
Memory corruption.
Privilege beyond the affected ACL identity.

Root Cause

fs/smb/server/vfs.c:ksmbd_vfs_inherit_posix_acl() obtains the parent's
default ACL, changes ACL_MASK to 0x07, and installs it as the child's
access ACL.

For directories, it also installs the widened ACL as the child's default ACL.

The SMB CREATE path in fs/smb/server/smb2pdu.c invokes this helper
after object creation.

Reproducer

I have a tested Python source reproducer using Impacket.

The reproducer:

Creates matched local and SMB children.
Records their resulting ACLs.
Verifies denial on the locally created control object.
Verifies successful read and overwrite access on the SMB-created object.

It contains no binary-only components.

Because AI assistance was used to review and package this report, I am
treating the report as public and am not attaching the reproducer to
this public message. I can provide the Python source and retained
evidence privately upon request.

Suggested Fix

Preserve the VFS-computed inherited ACL and inherited mask.
Do not force ACL_MASK to rwx.
Do not modify a referenced parent ACL object in place.
If KSMBD must transform an ACL, clone it first and ensure that the
resulting effective permissions never exceed normal POSIX inheritance
or the requested object creation mode.

A regression test should compare local and SMB object creation using
two principals and verify both file inheritance and directory default
ACL propagation.

Temporary Mitigation

Until a fix is available, avoid KSMBD shares whose parent default ACLs
rely on a restrictive mask to suppress broader named user or group
entries.

Where possible:

Remove dormant broader ACL entries, or
Use another SMB server implementation for the affected share.

I am available to retest a proposed fix using the same disposable
two-principal test environment.

Regards,

Charles Vosburgh