Bug 2544499

Summary: CVE-2026-76642 util-linux: util-linux: failed external mount helper still runs privileged X-mount post-hooks [fedora-all]
Product: [Fedora] Fedora Reporter: Tomas Hoger <thoger>
Component: util-linuxAssignee: Karel Zak <kzak>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: rawhideCC: artem, kzak
Target Milestone: ---Keywords: Security, SecurityTracking
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: {"flaws": ["b4249e54-8d4e-4bcd-bfb1-f89aed9a67e3"]}
Fixed In Version: Doc Type: ---
Doc Text:
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:    
Bug Blocks: 2521999    
Attachments:
Description Flags
proposed patch none

Description Tomas Hoger 2026-10-01 09:55:24 UTC 
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

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 v2.42.2 (dynamically confirmed on 2.41-5, 2.42.2-2, and 0f119878). Fixed in util-linux v2.41.6 and v2.42.3 (GHSA-m25x-3hj9-m26f, published 2026-09-02). Reported upstream by 4drez and S0S4.
Comment 1 Artem Dinaburg 2026-10-16 19:30:43 UTC 
Created attachment 2161369 [details]
proposed patch
Comment 2 Artem Dinaburg 2026-10-16 19:31:10 UTC 
Hello,

I'd like to offer a backport of the CVE-2026-76642 fix for Fedora 43 and 44, which both still
ship util-linux 2.41.5. Fedora 45 and Rawhide are already fixed in 2.42.4.

When an external mount.<type> helper fails, libmount looks at whether the helper was started
rather than whether the mount succeeded, so it still runs the post-mount hooks. Upstream
describes two consequences: X-mount.idmap can create an idmapped overmount of the original
target that ignores nosuid/nodev/noexec, and X-mount.owner/group/mode can change the ownership
and mode of the underlying target directory even though nothing was mounted.

The attached patch is upstream's stable/v2.41 commit a15c00a9e545 (cherry-picked from
f57cea130839, and released in 2.41.6). It skips both post-mount hook stages when the helper
or mount syscall has failed, and makes the loop-device hook release its device when its
cleanup hook is skipped. The code is unchanged from upstream; only the line offsets differ
because of Fedora's EROFS patch.

The patch applies cleanly, without fuzz, to the current f43 and f44 sources after the existing
Fedora patches. I also applied it to the f44 source earlier and built libmount successfully.
I have not run a live mount-helper test or a Mock/RPM build. Since 2.41.6 contains this fix,
rebasing to it would also work if you prefer.

AI assistance was used to prepare this patch and its validation. The resulting
changes and validation results were reviewed by a human.

Could you take a look and consider it for the f43/f44 updates? I'm happy to adjust it if
needed.

Thanks!