---
id: CVE-2025-38499
title: >-
  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…
summary: >-
  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…
severity: high
cvss: 7.8
cvssVector: 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'
vendor: linux
product: linux_kernel
affected:
  - 'linux_kernel >= 4.4.281, < 4.5'
  - 'linux_kernel >= 4.9.280, < 4.10'
  - 'linux_kernel >= 4.14.244, < 4.15'
  - 'linux_kernel >= 4.19.204, < 4.20'
  - 'linux_kernel >= 5.4.141, < 5.5'
  - 'linux_kernel >= 5.10.59, < 5.11'
  - 'linux_kernel >= 5.13.11, < 5.14'
  - 'linux_kernel >= 5.14.1, < 5.15.190'
  - 'linux_kernel >= 5.16, < 6.1.147'
  - 'linux_kernel >= 6.2, < 6.6.100'
  - 'linux_kernel >= 6.7, < 6.12.40'
  - 'linux_kernel >= 6.13, < 6.15.3'
  - linux_kernel = 5.14
  - debian_linux = 11.0
patched:
  - linux_kernel 6.15.3
published: '2025-08-11'
updated: '2026-10-15'
sourceUpdated: '2026-10-15T22:18:43.140'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2025-38499'
references:
  - url: 'https://git.kernel.org/stable/c/36fecd740de2d542d2091d65d36554ee2bcf9c65'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/38628ae06e2a37770cd794802a3f1310cf9846e3'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/c28f922c9dcee0e4876a2c095939d77fe7e15116'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/d717325b5ecf2a40daca85c61923e17f32306179'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/dc6a664089f10eab0fb36b6e4f705022210191d2'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/e77078e52fbf018ab986efb3c79065ab35025607'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html'
    label: af854a3a-2127-422b-91ae-364da2661108
  - url: 'https://cert-portal.siemens.com/productcert/html/ssa-082556.html'
    label: 0b142b55-0307-4c5a-b3c9-f314f3fb7c5e
tags:
  - nvd
  - cve.org
epss: 0.00163
epssPercentile: 0.05508
ssvc:
  exploitation: none
  automatable: 'no'
  technicalImpact: total
  timestamp: '2026-10-15T21:50:58.387852Z'
ingestedAt: '2026-10-15T05:52:46.084Z'
---

## Overview

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.

## Affected

- `linux_kernel >= 4.4.281, < 4.5`
- `linux_kernel >= 4.9.280, < 4.10`
- `linux_kernel >= 4.14.244, < 4.15`
- `linux_kernel >= 4.19.204, < 4.20`
- `linux_kernel >= 5.4.141, < 5.5`
- `linux_kernel >= 5.10.59, < 5.11`
- `linux_kernel >= 5.13.11, < 5.14`
- `linux_kernel >= 5.14.1, < 5.15.190`
- `linux_kernel >= 5.16, < 6.1.147`
- `linux_kernel >= 6.2, < 6.6.100`
- `linux_kernel >= 6.7, < 6.12.40`
- `linux_kernel >= 6.13, < 6.15.3`
- `linux_kernel = 5.14`
- `debian_linux = 11.0`

## Remediation

Upgrade past the affected range:

- `linux_kernel 6.15.3`