FlawAtlas
Search the atlas
CVE-2025-38499 Not scored

clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns

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.

Exploit probability 0.1%
Published August 11, 2025
Required by Not available
Last source change July 15, 2026

02 / AFFECTED SOFTWARE

Affected packages

Linux Kernel
Unknown Unknown

1898 explicit affected versions

03 / CONNECTIONS

Connected vulnerabilities

related ALSA-2025:23241
related ALSA-2025:23279
related OPENSUSE-SU-2025:20081-1
related SUSE-SU-2025:03204-1
related SUSE-SU-2025:03272-1
related SUSE-SU-2025:03283-1
related SUSE-SU-2025:03290-1
related SUSE-SU-2025:03301-1
related SUSE-SU-2025:03310-1
related SUSE-SU-2025:03314-1
related SUSE-SU-2025:03344-1
related SUSE-SU-2025:03382-1
related SUSE-SU-2025:03383-1
related SUSE-SU-2025:03384-1
related SUSE-SU-2025:03602-1
related SUSE-SU-2025:03633-1
related SUSE-SU-2025:03634-1
related SUSE-SU-2025:03636-1
related SUSE-SU-2025:03638-1
related SUSE-SU-2025:03643-1
related SUSE-SU-2025:03646-1
related SUSE-SU-2025:03650-1
related SUSE-SU-2025:03652-1
related SUSE-SU-2025:03653-1
related SUSE-SU-2025:03656-1
related SUSE-SU-2025:03662-1
related SUSE-SU-2025:03663-1
related SUSE-SU-2025:03664-1
related SUSE-SU-2025:03666-1
related SUSE-SU-2025:03671-1
related SUSE-SU-2025:03672-1
related SUSE-SU-2025:20653-1
related SUSE-SU-2025:20669-1
related SUSE-SU-2025:20739-1
related SUSE-SU-2025:20756-1
related SUSE-SU-2025:20873-1
related SUSE-SU-2025:20874-1
related SUSE-SU-2025:20875-1
related SUSE-SU-2025:20876-1
related SUSE-SU-2025:20877-1
related SUSE-SU-2025:20878-1
related SUSE-SU-2025:20879-1
related SUSE-SU-2025:20880-1
related SUSE-SU-2025:20881-1
related SUSE-SU-2025:20882-1
related SUSE-SU-2025:20883-1
related SUSE-SU-2025:20884-1
related SUSE-SU-2025:20885-1
related SUSE-SU-2025:20886-1
related SUSE-SU-2025:20887-1
related SUSE-SU-2025:20888-1
related SUSE-SU-2025:20889-1
related SUSE-SU-2025:20890-1
related SUSE-SU-2025:20891-1
related SUSE-SU-2025:20902-1
related SUSE-SU-2025:20903-1
related SUSE-SU-2025:20904-1
related SUSE-SU-2025:20905-1
related SUSE-SU-2025:20906-1
related SUSE-SU-2025:20907-1
related SUSE-SU-2025:20908-1
related SUSE-SU-2025:20909-1
related SUSE-SU-2025:20912-1
related SUSE-SU-2025:20913-1
related SUSE-SU-2025:20914-1
related SUSE-SU-2025:20915-1
related SUSE-SU-2025:20916-1
related SUSE-SU-2025:20917-1
related SUSE-SU-2025:20918-1
related SUSE-SU-2025:20919-1
related SUSE-SU-2025:20920-1
related SUSE-SU-2025:21074-1
related SUSE-SU-2025:21139-1
related SUSE-SU-2025:21179-1
related SUSE-SU-2025:3675-1
related SUSE-SU-2025:3679-1
related SUSE-SU-2025:3683-1
related SUSE-SU-2025:3703-1
related SUSE-SU-2025:3704-1
related SUSE-SU-2025:3705-1
related SUSE-SU-2025:3712-1
related SUSE-SU-2025:3717-1
related SUSE-SU-2025:3720-1
related SUSE-SU-2025:3721-1
related SUSE-SU-2025:3731-1
related SUSE-SU-2025:3733-1
related SUSE-SU-2025:3734-1
related SUSE-SU-2025:3736-1
related SUSE-SU-2025:3740-1
related SUSE-SU-2025:3742-1
related SUSE-SU-2025:3748-1
related SUSE-SU-2025:3755-1
related SUSE-SU-2025:3762-1
related SUSE-SU-2025:3764-1
related SUSE-SU-2025:3765-1
related SUSE-SU-2025:3768-1
related SUSE-SU-2025:3770-1
related SUSE-SU-2025:3771-1
related SUSE-SU-2025:3772-1
related SUSE-SU-2025:4123-1

04 / EVIDENCE

Source records

Open Source Vulnerabilities CVE-2025-38499

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.

View original source

05 / REFERENCES

Further evidence