REDHAT-BUG-2522684: High severity util-linux mount vulnerability
Restricted-user bind/rbind mounts authorize the source from /etc/fstab but do not pin that source inode before the privileged mount. libmount later opens the source as a pathname via opentree(ATFDCWD, source, OPENTREECLONE|...) (mntcontextopentree in context.c / hookmount.c). A local unprivileged user who can replace the fstab bind source or a writable ancestor with a symlink can redirect SUID mount(8) to bind an attacker-selected host directory. When the same fstab entry includes X-mount.owner=, X-mount.group=, or X-mount.mode=, hookowner.c then applies root-privileged fchownat()/chmod() to the mounted root, which for a bind mount is the redirected source inode. This is a source-side pathname TOCTOU; current HEAD already pins the target and uses fd-based owner hooks (the CVE-2026-53612 target-path fix), but that fd now refers to the attacker-redirected bind source. Distinct from the public loop backing-file TOCTOU and from CVE-2026-76642 (failed external helper still running post-hooks). X-mount.owner/group/mode was introduced with v2.39; no upstream fix as of 2026-08-24. Reported upstream by Alex0Young. GHSA-rh77-686x-2f2m.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
A local unprivileged user must be able to replace the bind-mount source named in /etc/fstab, or replace a writable ancestor of that source with a symlink. The vulnerable path involves restricted-user bind or rbind mounts invoked through SUID mount(8).
What makes the impact more severe than an unintended bind mount?
If the same fstab entry uses X-mount.owner=, X-mount.group=, or X-mount.mode=, mount applies root-privileged ownership or mode changes to the mounted root. For a redirected bind mount, those changes affect the attacker-selected source inode or directory.
Are all util-linux mount configurations affected?
The issue concerns fstab bind or rbind entries available to restricted users where the source pathname, or one of its ancestors, can be replaced by an unprivileged user. The ownership and permission-changing consequence requires X-mount.owner=, X-mount.group=, or X-mount.mode=, which were introduced in v2.39.
How can administrators identify potentially affected entries?
Review /etc/fstab for bind or rbind entries usable by restricted users, then determine whether their source paths or parent directories are writable by unprivileged users. Prioritize entries that also specify X-mount.owner=, X-mount.group=, or X-mount.mode=.
Is an upstream fix available?
No upstream fix was available as of 2026-08-24. The existing target-path protection and fd-based owner hooks do not prevent redirection of the bind source in this issue.