Cloudanix VulnDB

CVE-2026-99172

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug can leak internal resources when certain setup operations fail, slowly using up memory on systems that create many isolated environments.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Theoretical
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

A long-term mqueue mount created with fc_mount_longterm() in mq_init_ns() is leaked when later setup steps in create_ipc_ns() fail, because mntput() takes the fast path and never triggers unmount or superblock release.

Why it matters to the business

Repeated triggering of IPC namespace creation failures slowly leaks kernel mounts and superblocks, increasing memory pressure and potentially exhausting resources on systems that create many namespaces.

How an attack unfolds

An attacker with the ability to trigger repeated failures in mqueue or ipc sysctl setup (for example via crafted namespace creation sequences) can cause the kernel to leak mounts without any cleanup path, gradually consuming kernel resources.

How to fix it

Update to a kernel containing the fix that replaces mntput() with kern_unmount() in the failure path of create_ipc_ns() and free_ipc().

How to confirm the fix worked

Confirm the presence of kern_unmount() in the mq_init_ns() failure handling paths and verify that mqueue mounts are properly released on namespace creation errors.

Typical attack path

  1. Obtain privileges sufficient to create IPC namespaces or trigger sysctl setup paths
  2. Induce failure after mq_init_ns() succeeds but before namespace finalization
  3. Repeat to accumulate leaked mounts and superblocks
  4. Observe gradual kernel memory or mount table growth

How to detect it

Look for repeated IPC namespace creation failures in kernel logs combined with increasing mount or dentry counts that are never released; examine slab or mount-related counters for unexplained growth.

What your security team should do

  • Prioritize kernel updates containing the described mount cleanup fix
  • Monitor systems for unexpected growth in mount or superblock counts under namespace-heavy workloads
  • Limit untrusted code that can create IPC namespaces until patches are applied

The record

In the Linux kernel, the following vulnerability has been resolved: ipc: drop the mqueue mount with kern_unmount() on setup failure mq_init_ns() creates the mqueue mount with fc_mount_longterm(), so its ->mnt_ns is MNT_NS_INTERNAL. When setting up the mqueue or ipc sysctls or msg_init_ns() fails afterwards, create_ipc_ns() drops it with a plain mntput(). With ->mnt_ns set that takes the fast path of mntput_no_expire(). The count drops to zero and nothing ever kills the mount, so the mount and the mqueue superblock are leaked. Commit dc55e35f9e81 ("ipc: Store mqueue sysctls in the ipc namespace") added the first failure path after mq_init_ns() and never dropped the mount. Commit 7229d74e5e8c ("ipc: create_ipc_ns: drop mqueue mount on sysctl setup failure") tried to fix that with a mntput() but that doesn't help for a long-term mount. Use kern_unmount(). free_ipc() open-codes the same thing for a namespace that made it.

Affected packages

Ecosystem Package Introduced Fixed