[<prev] [day] [month] [year] [list]
Message-ID: <2025081112-CVE-2025-38499-4572@gregkh>
Date: Mon, 11 Aug 2025 18:01:13 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-38499: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns
From: Greg Kroah-Hartman <gregkh@...nel.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.
The Linux kernel CVE team has assigned CVE-2025-38499 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.14 with commit 427215d85e8d1476da1a86b8d67aceb485eb3631 and fixed in 6.1.147 with commit d717325b5ecf2a40daca85c61923e17f32306179
Issue introduced in 5.14 with commit 427215d85e8d1476da1a86b8d67aceb485eb3631 and fixed in 6.6.100 with commit dc6a664089f10eab0fb36b6e4f705022210191d2
Issue introduced in 5.14 with commit 427215d85e8d1476da1a86b8d67aceb485eb3631 and fixed in 6.12.40 with commit e77078e52fbf018ab986efb3c79065ab35025607
Issue introduced in 5.14 with commit 427215d85e8d1476da1a86b8d67aceb485eb3631 and fixed in 6.15.3 with commit 38628ae06e2a37770cd794802a3f1310cf9846e3
Issue introduced in 5.14 with commit 427215d85e8d1476da1a86b8d67aceb485eb3631 and fixed in 6.16 with commit c28f922c9dcee0e4876a2c095939d77fe7e15116
Issue introduced in 4.4.281 with commit c6e8810d25295acb40a7b69ed3962ff181919571
Issue introduced in 4.9.280 with commit e3eee87c846dc47f6d8eb6d85e7271f24122a279
Issue introduced in 4.14.244 with commit 517b875dfbf58f0c6c9e32dc90f5cf42d71a42ce
Issue introduced in 4.19.204 with commit 963d85d630dabe75a3cfde44a006fec3304d07b8
Issue introduced in 5.4.141 with commit 812f39ed5b0b7f34868736de3055c92c7c4cf459
Issue introduced in 5.10.59 with commit 6a002d48a66076524f67098132538bef17e8445e
Issue introduced in 5.13.11 with commit 41812f4b84484530057513478c6770590347dc30
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2025-38499
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
fs/namespace.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/d717325b5ecf2a40daca85c61923e17f32306179
https://git.kernel.org/stable/c/dc6a664089f10eab0fb36b6e4f705022210191d2
https://git.kernel.org/stable/c/e77078e52fbf018ab986efb3c79065ab35025607
https://git.kernel.org/stable/c/38628ae06e2a37770cd794802a3f1310cf9846e3
https://git.kernel.org/stable/c/c28f922c9dcee0e4876a2c095939d77fe7e15116
Powered by blists - more mailing lists