Fedora Account System
Red Hat Associate
Red Hat Customer
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.
Created attachment 2161369 [details] proposed patch
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!