CVE-2026-99172: ipc: drop the mqueue mount with kern_unmount() on setup failure
In the Linux kernel, the following vulnerability has been resolved:
ipc: drop the mqueue mount with kernunmount() on setup failure
mqinitns() creates the mqueue mount with fcmountlongterm(), so its ->mntns is MNTNSINTERNAL. When setting up the mqueue or ipc sysctls or msginitns() fails afterwards, createipcns() drops it with a plain mntput(). With ->mntns set that takes the fast path of mntputnoexpire(). 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 mqinitns() and never dropped the mount. Commit 7229d74e5e8c ("ipc: createipcns: 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 kernunmount(). freeipc() open-codes the same thing for a namespace that made it.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for this leak to occur?
An IPC namespace creation attempt must reach mq_init_ns() and then fail while setting up mqueue sysctls, IPC sysctls, or msg_init_ns(). The affected cleanup paths drop a long-term mqueue mount with mntput() rather than kern_unmount().
What is the practical impact of a failed namespace setup?
The mqueue mount and its mqueue superblock can remain leaked after the failed IPC namespace setup. This is a resource leak rather than a successful creation of a usable IPC namespace.
Which cleanup paths are implicated?
The failure handling in create_ipc_ns() is affected after mqueue initialization has succeeded but later setup fails. free_ipc() also contains equivalent cleanup behavior for a namespace that was created.