CVE-2025-38499
Description
In the Linux kernel, the following vulnerability has been resolved:
clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns
What we want is to verify there is that clone won't expose something hidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo" may be a result of MNT_LOCKED on a child, but it may also come from lacking admin rights in the userns of the namespace mount belongs to.
clone_private_mnt() checks the former, but not the latter.
There's a number of rather confusing CAP_SYS_ADMIN checks in various userns during the mount, especially with the new mount API; they serve different purposes and in case of clone_private_mnt() they usually, but not always end up covering the missing check mentioned above.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Linux kernel missing CAP_SYS_ADMIN check in clone_private_mnt() could allow unprivileged users to expose hidden mounts in certain user namespaces.
Vulnerability
Analysis The vulnerability CVE-2025-38499 resides in the Linux kernel's clone_private_mnt() function. This function is responsible for cloning a private mount point. The function checks whether a child mount has the MNT_LOCKED flag, which prevents unmounting, but it fails to verify that the caller possesses CAP_SYS_ADMIN in the user namespace to which the mount belongs [1]. This missing capability check can lead to situations where a mount that is effectively hidden (e.g., due to lack of administrator rights to undo the mount) becomes exposed through a clone operation.
Attack
Vector and Prerequisites To exploit this vulnerability, an attacker must be able to trigger a mount clone operation via clone_private_mnt() while lacking proper CAP_SYS_ADMIN privileges in the relevant user namespace. The bug means that an attacker who can create a mount and then clone it could bypass the intended privilege checks. However, in typical scenarios, the attacker would need some level of access to the system to perform mount operations, though the exact prerequisites depend on the kernel configuration and the use of user namespaces [1][2].
Impact
If successfully exploited, an attacker could expose mount points that should remain hidden or protected by the lack of administrative rights in the owning user namespace. This could lead to information disclosure or potential privilege escalation by revealing file system resources that are normally inaccessible. The CVSS v3 base score is 5.5 (Medium), reflecting a moderate severity [1].
Mitigation
The Linux kernel community has addressed this issue by adding the missing CAP_SYS_ADMIN check in clone_private_mnt(). The fix has been backported to stable kernel trees, as seen in commits like those referenced in the patch series [2][3][4]. Users should apply the latest kernel updates from their distribution to resolve this vulnerability. Siemens also lists affected products, such as SIMATIC S7-1500 CPUs, and recommends firmware updates as per their security advisory [1].
AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2- Linux/Linuxv5Range: 5.14
Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
8- git.kernel.org/stable/c/36fecd740de2d542d2091d65d36554ee2bcf9c65nvdPatch
- git.kernel.org/stable/c/38628ae06e2a37770cd794802a3f1310cf9846e3nvdPatch
- git.kernel.org/stable/c/c28f922c9dcee0e4876a2c095939d77fe7e15116nvdPatch
- git.kernel.org/stable/c/d717325b5ecf2a40daca85c61923e17f32306179nvdPatch
- git.kernel.org/stable/c/dc6a664089f10eab0fb36b6e4f705022210191d2nvdPatch
- git.kernel.org/stable/c/e77078e52fbf018ab986efb3c79065ab35025607nvdPatch
- lists.debian.org/debian-lts-announce/2025/10/msg00008.htmlnvdThird Party Advisory
- cert-portal.siemens.com/productcert/html/ssa-082556.htmlnvd
News mentions
0No linked articles in our index yet.