CVE-2026-78410: Util-linux: util-linux: restricted bind mounts do not pin the source, allowing x-mount.owner/group/mode redirection
A flaw was found in util-linux. Restricted bind mounts take the source path from fstab but do not pin that source before the privileged mount. A local unprivileged user who can replace the authorized source or a writable ancestor can redirect SUID mount(8) to bind another host directory. If the fstab entry also sets X-mount.owner, X-mount.group, or X-mount.mode, root then changes ownership or mode on that redirected inode.
Other sources
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.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems using restricted-user bind or rbind mounts authorized through /etc/fstab are exposed when a local unprivileged user can replace the authorized source path or a writable ancestor. Exploitation additionally depends on the privileged SUID mount(8) path being used.
What does an attacker need to exploit it?
An attacker needs local unprivileged access and the ability to replace the fstab-authorized bind source, or a writable directory ancestor, with a symlink that redirects resolution to an attacker-selected host directory. No user interaction is required.
When does the issue lead to root-privileged ownership or permission changes?
The fstab entry must include X-mount.owner=, X-mount.group=, or X-mount.mode=. In that case, after redirecting the bind source, mount(8) can apply root-privileged ownership or mode changes to the redirected source inode.
Are ordinary bind mounts necessarily affected?
The provided information specifically identifies restricted-user bind and rbind mounts authorized from /etc/fstab. It does not establish that ordinary bind mounts outside that restricted-user configuration are affected.