Cloudanix VulnDB

CVE-2026-98994

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A recently discovered flaw in the Linux kernel can let a regular user crash the whole computer or potentially take it over by exploiting a timing issue with file system mounts.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in statmount_mnt_basic allows concurrent unmount to free a mount's parent while the function reads mnt_parent twice under only namespace_sem, leading to use-after-free dereference of an already-unmounted mount structure.

Why it matters to the business

Local users can trigger kernel crashes or memory corruption on systems running affected kernels, causing denial of service and potential escalation to full system compromise; the bug is two days old with no known exploitation yet but requires prompt kernel updates across all Linux deployments.

How an attack unfolds

An attacker obtains a file descriptor to a mount that will be unmounted, triggers the unmount sequence while concurrently calling statmount with STATMOUNT_BY_FD on that descriptor, and wins the race so that the second mnt_parent read occurs after the parent has been freed under mount_lock.

How to fix it

Apply the upstream fix that performs both parent reads under mount_lock; rebuild and deploy updated kernels to all affected systems as soon as vendor packages are available.

How to confirm the fix worked

Confirm the kernel source contains the mount_lock acquisition around the mnt_parent reads in statmount_mnt_basic; run existing mount and statmount test suites plus concurrency stress tests that exercise unmounted mounts held only by file descriptors.

Typical attack path

  1. Obtain file descriptor referencing a mount that can be unmounted
  2. Initiate unmount of the target mount and its parent
  3. Concurrently invoke statmount using STATMOUNT_BY_FD on the retained descriptor
  4. Win the timing window so the second parent pointer read occurs after free
  5. Trigger use-after-free dereference to crash or corrupt kernel memory

How to detect it

Review kernel logs for oops/panic entries mentioning statmount_mnt_basic or mnt_parent; inspect auditd or syscall traces for unusual sequences of mount, unmount, and statmount calls from unprivileged processes.

What your security team should do

  • Prioritize kernel updates on all multi-user and internet-facing Linux systems within the next 7 days
  • Restrict unprivileged mount namespace creation via kernel.unprivileged_userns_clone or similar sysctls until patches are deployed
  • Monitor for kernel oops or panic logs referencing statmount or mnt_parent

The record

In the Linux kernel, the following vulnerability has been resolved: statmount: read the parent of an unmounted mount under mount_lock statmount_mnt_basic() reads the ids of the parent through m->mnt_parent with namespace_sem held for reading. That's fine for a mount that is in a namespace. Everything above it is pinned by that namespace. STATMOUNT_BY_FD also accepts a file descriptor on a mount that has been unmounted on purpose and that only the file descriptor keeps alive. If that mount stayed attached to its parent when it was unmounted the parent is unmounted as well and nothing pins it for the child. The final mntput() unmounts the children under mount_lock alone and frees the parent afterwards. Concurrently, statmount_mnt_basic() reads m->mnt_parent twice while that can happen and can easily dereference a mount that's already gone. Read the parent of an unmounted mount under mount_lock. The parent can't be put while it is held and both ids come from the same mount. A mounted mount's parent is pinned by the namespace and a mount can't leave its namespace while namespace_sem is held, so the common case takes no global lock.

Affected packages

Ecosystem Package Introduced Fixed