high

CVE

CVE-2026-53612, CVE-2026-53613, CVE-2026-53614

CWE

CWE-367

Affected Surface

  • util-linux `2.39` through `2.41.4` and `2.42` through `2.42.1` for `CVE-2026-53612` and `CVE-2026-53614`
  • util-linux `2.17` through `2.41.6` and `2.42` through `2.42.3` for `CVE-2026-53613`, plus `2.42.4` when the legacy `mount(2)` fallback runs without `/proc`
  • Linux distributions that ship SUID `/usr/bin/mount` and allow non-root `user` or `users` mounts through `/etc/fstab`
  • Developer workstations, self-hosted CI runners, lab hosts, and shared build machines where a first-stage compromise can already run low-privilege code
  • Systems using `X-mount.mode=`, `X-mount.owner=`, or `X-mount.group=` on user-authorized mount points

The strongest Linux item from the last three days is a cluster of util-linux mount bugs that landed in NVD on 14 October. They are local bugs, not remote entry points, but they still belong in an AppSec research feed because they change the blast radius of a package compromise, a poisoned build step, or any other low-privilege foothold on a Linux host.

The affected binary is familiar: SUID /usr/bin/mount. If a workstation, runner, or shared lab machine lets ordinary users mount filesystems through /etc/fstab, these bugs turn small pathname mistakes into root-level effects. The useful lesson is not “mount had three unrelated bugs.” It is that util-linux kept checking one filesystem object and then acting on a pathname or legacy mount flow that could point somewhere else by the time the privileged step ran.

What changed this week

Three related CVEs now describe three different trust-boundary failures in restricted, non-root mount flows:

CVECore mistakePractical outcomeCurrent fixed-state detail
CVE-2026-53612post-mount chmod() / lchown() re-used the target pathname after the mount finishedattacker can redirect mode or ownership changes onto root-owned pathsfixed in 2.41.5 and 2.42.2
CVE-2026-53613target pathname was validated before the final mount, then re-resolved during mount() or move_mount()attacker can redirect an allowed user mount onto a root-owned location such as /etc/sudoers.d2.41.5 and 2.42.2 pin the new mount API target; 2.42.4 adds legacy-path pinning through /proc/self/fd; documented legacy fallback without /proc still matters
CVE-2026-53614attacker-controlled LIBMOUNT_FORCE_MOUNT2 could force the old mount path with a bind plus remount windownosuid, noexec, or nodev protections can be absent during the first step of a restricted bind mountfixed in 2.41.5 and 2.42.2

That version nuance on CVE-2026-53613 is important. The first upstream release notes describe the original fix, but NVD now tracks follow-up hardening too. If you only look at the first release note, you will under-scope the legacy path.

The shared bug class: validate one path, act on another

All three issues come down to the same shape:

restricted user mount request
  -> util-linux validates /etc/fstab target and user permissions
  -> attacker swaps a writable ancestor with renameat2(RENAME_EXCHANGE)
  -> privileged post-mount action or mount syscall re-resolves the path
  -> operation lands on an attacker-chosen root-owned object

That is why these bugs matter to application-security teams. Stage one can still be ordinary user code execution from a malicious package, a compromised CI task, or a service account shell. Stage two is what the host does with that foothold.

CVE-2026-53612: hook_owner.c changed permissions on a path string, not a pinned object

The clearest bug in the set is CVE-2026-53612. util-linux supported post-mount ownership and mode options such as X-mount.owner=, X-mount.group=, and X-mount.mode=. After the mount completed, hook_post() fetched the target path and applied lchown() and chmod() to that path string:

target = mnt_fs_get_target(cxt->fs);

if (hd->owner != (uid_t) -1 || hd->group != (uid_t) -1) {
    if (lchown(target, hd->owner, hd->group) == -1)
        return -MNT_ERR_CHOWN;
}

if (hd->mode != (mode_t) -1) {
    if (chmod(target, hd->mode) == -1)
        return -MNT_ERR_CHMOD;
}

The problem is timing. mount() had already succeeded. The follow-up chmod() or lchown() forced the kernel to resolve the pathname again. If an attacker could swap an ancestor directory in between, the privileged ownership or mode change hit a different object.

Upstream fixed that by moving the operation onto a pinned descriptor. The patch does two things that are worth reading closely:

if (mnt_context_target_fd_required(cxt))
    fd = mnt_context_get_target_fd(cxt);
else
    fd = open(target, O_PATH | O_CLOEXEC);

if (fchownat(fd, "", hd->owner, hd->group, AT_EMPTY_PATH) == -1)
    rc = -MNT_ERR_CHOWN;

The same patch switches mode changes to a descriptor-backed path under /proc/self/fd/<n>. That is the whole fix in one sentence: do not trust a pathname after the privilege boundary has already moved.

CVE-2026-53613: the target directory needed fd pinning before the final mount

CVE-2026-53613 sits earlier in the flow. The target path passed /etc/fstab matching and restricted-user permission checks, but the final mount() or move_mount() still re-resolved the pathname later. That left a race window where a user-writable ancestor could be swapped to redirect the mount itself.

The public advisory shows the vulnerable idea plainly:

target = mnt_fs_get_target(cxt->fs);
rc = move_mount(api->fd_tree, "", AT_FDCWD, target, MOVE_MOUNT_F_EMPTY_PATH);

and, on the legacy path:

if (mount(src, target, type, flags, options)) {
    ...
}

The early fix introduced a pinned target descriptor in libmnt_context and opened it with ul_open_no_symlinks() so symlinks in any path component are rejected:

if (target)
    cxt->fd_target = ul_open_no_symlinks(target, O_PATH | O_CLOEXEC, 0);

Then prepare_target() began pinning that descriptor before the mount stage runs:

if (rc == 0
    && mnt_context_target_fd_required(cxt)
    && mnt_context_get_target_fd(cxt) < 0) {
    rc = -errno;
}

The operational catch is that this CVE kept moving after the first disclosure. Current NVD text says 2.41.5 and 2.42.2 pin the target for the new mount API, while 2.42.4 adds legacy-target pinning through /proc/self/fd. If your environment can still drop into the documented legacy fallback without /proc, you cannot treat every 2.42.4 host as clean without checking the actual mount path in use.

CVE-2026-53614: LIBMOUNT_FORCE_MOUNT2 reopened the old two-step mount window

The third bug is different in detail but not in effect. util-linux exposed LIBMOUNT_FORCE_MOUNT2, and the mount code originally read it with plain getenv():

const char *env = getenv("LIBMOUNT_FORCE_MOUNT2");

That let a restricted user force the old mount(2) flow even in SUID context. The reason that matters is in the release notes and the fixing commit message: legacy bind plus remount and propagation changes are multi-step operations. There is a window between syscalls where security flags such as nosuid and noexec are not applied yet.

The patch does two simple but important things:

const char *env = safe_getenv("LIBMOUNT_FORCE_MOUNT2");

and, in the legacy mount hook, it refuses multi-step legacy mount sequences for restricted users:

if (flags & MS_PROPAGATION) {
    if (mnt_context_is_restricted(cxt))
        goto eperm;
}

if ((flags & MS_BIND) && (flags & MNT_BIND_SETTABLE) && !(flags & MS_REMOUNT)) {
    if (mnt_context_is_restricted(cxt))
        goto eperm;
}

This is a good example of a fix that removes a feature path instead of trying to make a brittle sequence safe after the fact. The new mount API can apply those properties atomically. The old bind-plus-remount path could not.

Why this is an AppSec problem and not just a Linux admin problem

These bugs do not create an initial foothold. They make a foothold worth more.

malicious package or hostile build step
  -> low-privilege code runs on developer or CI host
  -> attacker finds a user-authorized mount path in /etc/fstab
  -> util-linux mount bug turns that foothold into root

That is enough to put util-linux in scope for teams that normally start with package managers, not with the base OS. Shared runners, dev boxes with loop-mount workflows, lab machines, and container hosts with user-mount workflows all fit that model.

What to check on real hosts

Start with the installed util-linux and the actual mount binary:

mount --version
stat -c '%A %U %G %n' /usr/bin/mount

Then look for user-authorized mount points and the options that make these CVEs reachable:

rg -n '(^|[[:space:]])(user|users)(,|[[:space:]])|X-mount\\.(mode|owner|group)=' /etc/fstab

If those entries exist, check whether any ancestor directory is attacker-writable:

namei -om /path/from/fstab

For CVE-2026-53613, do not stop at package version alone. Confirm whether the host can still hit the legacy path and whether /proc is available in the relevant mount context. For CVE-2026-53614, look for environments that rely on restricted bind mounts plus nosuid, noexec, or nodev as their safety boundary.

Response guidance

  1. Patch util-linux to a fixed vendor build, not just the nearest upstream tag number.
  2. Re-check vendor notes for CVE-2026-53613, because the target-pinning story changed after the initial 2.41.5 and 2.42.2 fixes.
  3. Remove or tighten risky /etc/fstab entries that give ordinary users mount access under writable directory trees.
  4. Treat recently compromised workstations and CI runners as host-level incidents if they also had reachable user mounts.

The code lesson is plain. util-linux got safer when it stopped treating a security-checked path string as a durable identity. Once the fix moved from pathnames to pinned file descriptors, the bug class got much narrower. That is a useful pattern well beyond mount(8): if a privileged action depends on a filesystem object, keep hold of the object, not just the name you used to find it.

From research to remediation

Check whether this pattern exists in your codebase

Turn this research into a remediation workflow. Scan dependencies and package manifests for similar supply-chain risk, then prioritize fixes with reachability context.

Explore dependency scanning Get Demo

References