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.

Metrics

No CVSS v4.0

Attack Vector Local

Attack Complexity High

Privileges Required Low

Scope Unchanged

Confidentiality Impact High

Integrity Impact High

Availability Impact High

User Interaction None

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

Key SSVC decision points have not yet been added.

Affected Vendors & Products

Vendors Products
Linux
  • Linux Kernel

No data.

No data.

References
Link Providers
https://git.kernel.org/stable/c/38628ae06e2a37770cd794802a3f1310cf9846e3 cve-icon cve-icon
https://git.kernel.org/stable/c/c28f922c9dcee0e4876a2c095939d77fe7e15116 cve-icon cve-icon
https://git.kernel.org/stable/c/d717325b5ecf2a40daca85c61923e17f32306179 cve-icon cve-icon
https://git.kernel.org/stable/c/dc6a664089f10eab0fb36b6e4f705022210191d2 cve-icon cve-icon
https://git.kernel.org/stable/c/e77078e52fbf018ab986efb3c79065ab35025607 cve-icon cve-icon
https://lore.kernel.org/linux-cve-announce/2025081112-CVE-2025-38499-4572@gregkh/T cve-icon
https://nvd.nist.gov/vuln/detail/CVE-2025-38499 cve-icon
https://www.cve.org/CVERecord?id=CVE-2025-38499 cve-icon
History

Tue, 12 Aug 2025 07:45:00 +0000

Type Values Removed Values Added
First Time appeared Linux
Linux linux Kernel
Vendors & Products Linux
Linux linux Kernel

Tue, 12 Aug 2025 00:15:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

 cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Moderate

Mon, 11 Aug 2025 16:15:00 +0000

Type Values Removed Values Added
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.
Title clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns
References
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2025-08-11T16:01:08.257Z

Reserved: 2025-04-16T04:51:24.022Z

Link: CVE-2025-38499

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2025-08-11T16:15:30.057

Modified: 2025-08-11T18:32:48.867

Link: CVE-2025-38499

cve-icon Redhat

Severity : Moderate

Publid Date: 2025-08-11T00:00:00Z

Links: CVE-2025-38499 - Bugzilla