Bug 2521999 (CVE-2026-76642)

Summary: CVE-2026-76642 util-linux: util-linux: failed external mount helper still runs privileged X-mount post-hooks
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: akhatavk, aos-team-art-private, asdas, crizzo, dpaolell, gtanzill, jbuscemi, jdelft, jupierce, kshier, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rhel-process-autobot, security-response-team, sghai, sidsharm, stcannon, suppawar, teagle, vlaad, watson-tool-maintainers, yguenane
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
When an external mount.<type> helper runs but exits with a nonzero status, libmount still treats the helper invocation as successful and runs privileged post-mount hooks. A local unprivileged user with an /etc/fstab entry that uses the user option together with X-mount.idmap or X-mount.owner/group/mode can cause those hooks to clone or re-own the underlying filesystem after the helper fails, leading to local 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:
Bug Depends On: 2544499    
Bug Blocks:    

Description OSIDB Bzimport 2026-08-24 15:06:58 UTC 
When an external mount.<type> helper executes but exits nonzero, libmount records the helper's failure in helper_status yet returns success from exec_helper() in context_mount.c. mnt_context_do_mount() then runs privileged MNT_STAGE_MOUNT_POST hooks as if the helper had mounted the requested filesystem. With an /etc/fstab entry usable by an unprivileged user that specifies X-mount.idmap, the idmap post-hook clones the pre-existing filesystem under the target (inheriting suid,exec from the underlying mount because helper-path VFS-flag application is skipped), enabling a local unprivileged user to obtain EUID 0. Independently, X-mount.owner/group/mode post-hooks can change ownership and mode of the physical target inode even when no mount was created. Exploitation requires SUID-root mount(8), a root-controlled fstab entry with the user option plus X-mount.idmap or X-mount.owner/group/mode, and an external helper that exits nonzero; the helper need not be malicious. This is distinct from CVE-2026-53612 (TOCTOU in hook_owner.c): there is no race or path substitution. Affects util-linux v2.39 through current master (dynamically confirmed on 2.41-5, 2.42.2-2, and 0f119878). No upstream fix as of 2026-08-24. Reported upstream by 4drez and S0S4. GHSA-m25x-3hj9-m26f.