CVE-2026-76642

A flaw was found in the util-linux libmount library, which Red Hat rates as Important severity. When an external mount. helper executes but exits with a nonzero status, libmount incorrectly treats the helper invocation as successful and runs privileged MNT_STAGE_MOUNT_POST hooks (X-mount.idmap, X-mount.owner/group/mode) as if the requested filesystem had been mounted. A local unprivileged user who can trigger a mount defined by a root-controlled /etc/fstab entry combining the user option with X-mount.idmap or X-mount.owner/group/mode can abuse this to escalate privileges: with X-mount.idmap, the idmap post-hook clones the pre-existing filesystem under the target, inheriting suid and exec flags from the underlying mount, which can allow the 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 the SUID-root mount(8) binary, a root-controlled user-mountable fstab entry with those X-mount.* options, and an external helper that exits nonzero; the helper itself need not be malicious. This flaw affects the util-linux component in Red Hat Enterprise Linux 10, Red Hat In-Vehicle OS, Red Hat Hardened Images, and certain container images, as well as Fedora in the community stream, where fixes are being pursued by the responsible engineering teams. Red Hat Enterprise Linux 7, 8, and 9, and Red Hat Enterprise Linux CoreOS (OpenShift Container Platform) are not affected because the vulnerable code is not present in their util-linux versions. Red Hat assigns this flaw a CVSS 3.1 base score of 7.8, while the upstream CVSS 4.0 score is 8.5; both place the flaw within Important severity. This issue is distinct from CVE-2026-53612, which involves a time-of-check race condition in the same post-hook code, whereas this flaw involves no race or path substitution.