Bug 2499991 (CVE-2026-15779)

Summary: CVE-2026-15779 samba-winbind: samba: pam_winbind mkhomedir chowns critical system paths without validation
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in samba's pam_winbind. When mkhomedir is enabled, pam_winbind chowns the target account's home directory without validating the path is not a critical system directory such as /. On affected systems, accounts with / as their home directory (a common default for system accounts) can have this triggered not only by root, but by a non-root user holding a narrow sudo delegation to run commands as that account, causing ownership of / to change and resulting in severe denial of service (SSH, sudo, and package-manager failures). The change does not grant write access to / (which ships with restrictive 0555 permissions on RHEL), so the impact is availability loss rather than further privilege escalation.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-07-14 14:19:30 UTC 
A flaw was found in samba's pam_winbind module. When pam_winbind.conf sets mkhomedir = yes, the module's _pam_mkhomedir()/_pam_chown_homedir() functions call chown() on the target account's home directory (pw_dir, taken directly from getpwnam()) without validating that the path is not a sensitive system directory. On RHEL, several stock system accounts (e.g. nobody, sssd, nscd) ship with / as their home directory by default in /etc/passwd. Opening a PAM session for such an account causes the root filesystem (/) to be chown'd to that account's uid/gid, breaking ownership checks relied on by sshd (StrictModes), sudo, and package tooling. Reproduced directly in an isolated sandbox using the exact affected NVRs: the trigger is not limited to root explicitly running su - nobody (the originally reported PoC) -- a non-root user holding only a narrow, common sudo delegation (e.g. 'someuser ALL=(nobody) NOPASSWD: ...') reaches the identical code path via the shared system-auth PAM stack included by sudo. Also confirmed: / ships with mode 0555 on RHEL, so the resulting ownership change does not grant the new owner write access to / (no arbitrary file creation/rename/deletion capability is gained); impact is denial of service via broken ownership checks, not privilege escalation via filesystem write access. Per the reporting bug (RHEL-178261), this was discovered during a customer penetration test (SFDC case 04452638). This flaw affects samba versions using the older _pam_chown_homedir() structure (samba 4.19.x/4.23.x, confirmed via source diff and live reproduction). A fix is gated and confirmed queued for RHEL 8.10.z (RHEL-178261, via RHBA-2026:169544, publishing 2026-07-28), RHEL 9.8.z (RHEL-180756, via RHBA-2026:168497, publishing 2026-08-04), and RHEL 10.2.z (RHEL-180758, via RHBA-2026:168496, publishing 2026-08-04) -- all three are non-security bug-fix errata. RHEL 9.9 and RHEL 10.3 ship samba 4.24.3, which refactored the affected code path upstream (chown() only fires when mkdir() creates a genuinely new directory, not when the target already exists) -- confirmed via live reproduction in isolated sandboxes using the exact NVRs those releases ship (samba-winbind-4.24.3-1.el9 and samba-winbind-4.24.3-100.el10) that neither su nor sudo-delegation triggers the chown. RHEL 9.9/10.3 are NOT AFFECTED.