CVE-2026-64388

This CVE exposes a silent correctness failure in the CIFS client that should change how you think about SMB3 POSIX Extensions in production. When posix_extensions are enabled on a mount, cifs_setattr_nounix() bypasses the id_mode_to_cifs_acl() call entirely. The syscall returns success (zero) to userspace, but the ownership change never reaches the server. The file appears owned by the new UID/GID locally while the server still holds the original owner. This is the dangerous category of invisible failures—every downstream security decision (ACL evaluations, container namespace isolation, compliance audits) operates on fictional state. The fix is a single posix_extensions check added to cifs_setattr_nounix(), and you should apply it immediately. But the patch closes one bug without addressing the structural question: this failure mode likely exists elsewhere in the same function. chmod, extended attributes, and ACL operations all depend on the same id_mapping infrastructure that silently dropped this chown. The engineering pressure that caused this bug—'the other path already handles permissions, we just need the compatibility flag'—almost certainly applied to every other permission-modifying operation in that codepath. Treat this as evidence of incomplete test coverage for POSIX extension paths, not a one-off. Audit your CIFS mounts for posix_extensions usage. For any workload where permission state must be reliable (containerized workloads with UID namespace isolation, compliance-sensitive file systems, multi-tenant mounts), verify actual server-side ownership matches what the kernel reports. The kernel API guarantees nothing about whether the operation reached the wire—this CVE is your evidence that the guarantee was already broken.

Reviewed through automated stages and approved by a human before publication.