CVE-2025-38499
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-08-11

Last updated on: 2025-11-03

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-08-11
Last Modified
2025-11-03
Generated
2026-05-07
AI Q&A
2025-08-11
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel 6.1.153
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel involves the clone_private_mnt() function, which did not properly verify that the caller has the CAP_SYS_ADMIN capability in the correct user namespace. This check is important to ensure that the clone operation does not expose mount points that are hidden or locked in a way that cannot be undone, potentially leading to unauthorized access or manipulation of mounts. The function previously checked for certain conditions like MNT_LOCKED but missed verifying admin rights in the user namespace, which could allow bypassing intended restrictions.


How can this vulnerability impact me? :

This vulnerability could allow a user or process without proper administrative rights in a user namespace to perform clone operations that expose or manipulate mount points that should be protected. This could lead to unauthorized access to filesystem mounts or the ability to interfere with mount namespaces, potentially compromising system security or isolation between containers or users.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart