Read the docs
TI-2026-79789 Aliases CVE-2026-98996GHSA-5j2w-v2xc-m3r3

Linux kernel silently unmounts busy mounts during propagation

Priority LOW 22Published · Updated

Key facts

Attack vector
—
Privileges required
—
User interaction
—
Attack complexity
—
Impact type
—
Confidentiality · integrity · availability
—
Fix status
Partial Red Hat: 7 without a fix

No CVSS vector from any source. Fix status from CNA and Red Hat.

Summary

The Linux kernel from 4.1.43 before 4.2, from 4.4.78 before 4.5, from 4.9.39 before 4.10, from 4.11.12 before 4.12, from 4.12.3 before 4.13, and from 4.13 is affected. The propagate_mount_busy() helper skips some copies of a mount being unmounted, so a synchronous unmount succeeds even though the mount is still in use. A local user who can create mounts in a container can trigger this to detach a mount that the host still uses.

Written with Claude Haiku 5.5 from the sources below · 2026-11-07

Description from the CNA

In the Linux kernel, the following vulnerability has been resolved: fs: don't silently unmount busy mounts The propagate_mount_busy() helper exists to decide whether a synchronous can suceed. It does that by looking at the copies of the victims in the mounts its parent propagates to. One of those functions from propagation hell. It skips a copy that has child mounts except for the case of a single child mount covering the copy's root. That algorithm used to be exact. It isn't anymore. Originally only childless copies were unmounted during propagation. And 1064f874abc0 ("mnt: Tuck mounts under others instead of creating shadow/side mounts.") ended up adding covered mounts to both sides in one go. Along came 99b19d16471e ("mnt: In propgate_umount handle visiting mounts in any order") and that started to unmount more than before: [1]: A copy of a mount is unmounted when each of its children is either its overmount or a copy of the victim itself. In the former case the overmount gets reparented. In the latter case the copy of the victim will end up being unmounted. So propagate_umount() ended up being rewritten without adjusting propagate_mount_busy(). And currently propagate_mount_busy() doesn't look at copies of the victim that have two or more children nor a single child that is not the overmount. So any such copy in [1] is not checked for references. The result is that a synchronous unmount succeeds, pulling out a mount that is still in use. A container can run into this with its own mounts. The host shares a tree with the container and the host has a mount in that tree: mount -t tmpfs none /mnt mount --make-shared /mnt mount -t tmpfs none /mnt/a The container's /mnt is a slave copy of the host mount. The container now takes a detached copy of the tree and mounts that copy beneath its propagated copy of /mnt/a and keeps the file descriptor to the tree open: unshare -m --propagation unchanged mount --make-rslave / fd = open_tree(AT_FDCWD, "/mnt", OPEN_TREE_CLONE | AT_RECURSIVE) move_mount(fd, "", AT_FDCWD, "/mnt/a", MOVE_MOUNT_BENEATH) grep /mnt /proc/self/mountinfo 775 355 ... /mnt ... master:646 777 775 ... /mnt/a ... master:646 776 777 ... /mnt/a ... master:647 778 777 ... /mnt/a/a ... master:647 The now attached tree (777) is now mounted beneath the container's copy of /mnt/a. That's also where the host mount sits (as seen from the host mount namespace). So the propagated copy (776) of the host's mount is on top of its root and the copy of that (778) is inside it. Now the host runs: umount /mnt/a and it succeeds. The moved tree tree and the copy inside of it are gone from the container. Now only the propagated copy is left and it got reparented to where it was before: grep /mnt /proc/self/mountinfo 775 355 ... /mnt ... master:646 776 775 ... /mnt/a ... But the file descriptor still refers to the moved tree. So a synchronous umount detached a mount that is still in use. Teach propagate_mount_busy() the same checks that propagate_umount() does. It now checks for a single victim mount without children for which it can assume that MNT_LOCKED is cleared on every copy like propagate_umount() does. The copies form chains. IOW, when a copy itself receives propagation from the victim's parent then the mount at the same mountpoint inside that copy is a copy as well. Whether a mount receives propagation from the victim's can simply be checked by walking its masters. Walk each chain once from its top so we are sure that nested copies stay linear. Check every reference once of every copy that gets unmounted.

Why it matters now

EPSS 0.00167 5th percentileScored 2026-11-07
Fix Partial Linux (Linux): 4.2, 4.5, 4.10 +5Red Hat: 7 without a fix

SSVC decision points

Not available: CISA has not published SSVC decision points for this record.

Affected products

VendorProductAffected versionsFixed inStatusSource
LinuxLinux4.1.43 to before 4.2; 4.4.78 to before 4.5; 4.9.39 to before 4.10; 4.11.12 to before 4.12; 4.12.3 to before 4.134.2, 4.5, 4.10, 4.12, 4.13Patch availableCNA
LinuxLinux4.13 and later6.18.57, 7.2.11, 7.3Patch availableCNA
  • Linux VendorLinux Affected 4.1.43 to before 4.2; 4.4.78 to before 4.5; 4.9.39 to before 4.10; 4.11.12 to before 4.12; 4.12.3 to before 4.13 Fixed in 4.2, 4.5, 4.10, 4.12, 4.13 Patch available CNA
  • Linux VendorLinux Affected 4.13 and later Fixed in 6.18.57, 7.2.11, 7.3 Patch available CNA

CPE names Threatist (inferred) · 1

Inferred from how NVD named this product before; not given by a source.

CPEVersionsRoleVendor
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*——Linux
  • cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* Versions — — ·Linux

Remediation

The Linux kernel is fixed in 4.2, 4.5, 4.10, 4.12, 4.13, 6.18.57, 7.2.11 and 7.3, so update to the fixed release for your branch. Red Hat Enterprise Linux 6 has no fix planned. Red Hat Enterprise Linux 7, 8, 9 and 10 and Red Hat OpenShift Container Platform 4 and 5 have no fix available yet.

Written with Claude Haiku 5.5 from the sources below · 2026-11-07

  • Fix · CNA Linux (Linux) Fixed in 4.2, 4.5, 4.10, 4.12, 4.13
  • Fix · CNA Linux (Linux) Fixed in 6.18.57, 7.2.11, 7.3

Vendor assessments

Red Hat

Red Hat rating: Low. Red Hat's page for this CVE →

ProductStatusPlan or fix
Red Hat Enterprise Linux 10AffectedNo fix yet: Fix deferred
Red Hat Enterprise Linux 6AffectedNo fix planned: Out of support scope
Red Hat Enterprise Linux 7AffectedNo fix yet: Fix deferred
Red Hat Enterprise Linux 8AffectedNo fix yet: Fix deferred
Red Hat Enterprise Linux 9AffectedNo fix yet: Fix deferred
Red Hat OpenShift Container Platform 4AffectedNo fix yet: Fix deferred
Red Hat OpenShift Container Platform 5AffectedNo fix yet: Fix deferred

Timeline

  1. 2026-10-23 Threatist record created from CVE-2026-98996
  2. 2026-10-23 Alias added: GHSA-5j2w-v2xc-m3r3
  3. 2026-10-29 Affected versions changed · Red Hat
  4. 2026-10-29 CVSS score added · Red Hat
  5. 2026-11-07 Affected versions changed · Red Hat

References

  • TI-2025-26358 tls: fix handling of zero-length records on the rx_list KEVCVSS 3.1CRITICAL 9.8
  • TI-2026-38352 netfilter: bridge: make ebt_snat ARP rewrite writable KEVCVSS 3.1HIGH 8.8
  • TI-2021-02452 Incorrect authorization in Ubuntu linux kernel KEVCVSS 3.1HIGH 8.8
  • TI-2013-05264 The (1) get_user and (2) put_user API functions in the Linux kernel before 3.5.5 on the… KEVCVSS 3.1HIGH 8.8
  • TI-2022-00125 Integer overflow in kernel KEVCVSS 3.1HIGH 8.4
  • TI-2013-01864 The perf_swevent_init function in kernel/events/core.c in the Linux kernel before 3.8.9… KEVCVSS 3.1HIGH 8.4
See all 21741 →

Sources