smb: client: validate the whole DACL before rewriting it in cifsacl
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.15.210, 6.1.176, 6.6.140, 6.12.86, 6.18.35, and 1 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
In the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs. Factor the DACL structural checks into validate_dacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parse_dacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From bc3e9dd9d104ca1b75644eab87b38ce8a924aef4 · fixed in b8603d9ae6c9087662b098619996bc4a8064319d; From bc3e9dd9d104ca1b75644eab87b38ce8a924aef4 · fixed in c2abdebf72000a64603ced84d36ccbd164f11391; From bc3e9dd9d104ca1b75644eab87b38ce8a924aef4 · fixed in 8e47d297e7cf9a6029a0d38e7b22faba7d7aaf12; From bc3e9dd9d104ca1b75644eab87b38ce8a924aef4 · fixed in d92f3f0b22414e7515696a02224d0af55e3004a3; From bc3e9dd9d104ca1b75644eab87b38ce8a924aef4 · fixed in ff0ca46b13b9ef6edbcd238a3b6caacfef8ba0e5; From bc3e9dd9d104ca1b75644eab87b38ce8a924aef4 · fixed in b78db9bddc84136f6a0bb49e8883cf200dfb87a8; From bc3e9dd9d104ca1b75644eab87b38ce8a924aef4 · fixed in 0a8cf165566ba55a39fd0f4de172119dd646d39a
- Linux Linux
5.12
- KernelLinux
From 5.12.0 · fixed in 5.15.210; From 5.16.0 · fixed in 6.1.176; From 6.2.0 · fixed in 6.6.140; From 6.7.0 · fixed in 6.12.86; From 6.13.0 · fixed in 6.18.35; From 6.19.0 · fixed in 7.0.2
References 7
git.kernel.org
- stable/c/b8603d9ae6c9087662b098619996bc4a8064319d
- stable/c/c2abdebf72000a64603ced84d36ccbd164f11391
- stable/c/8e47d297e7cf9a6029a0d38e7b22faba7d7aaf12
- stable/c/d92f3f0b22414e7515696a02224d0af55e3004a3
- stable/c/ff0ca46b13b9ef6edbcd238a3b6caacfef8ba0e5
- stable/c/b78db9bddc84136f6a0bb49e8883cf200dfb87a8
- stable/c/0a8cf165566ba55a39fd0f4de172119dd646d39a