__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock
... or we risk stealing final mntput from sync umount - raising mnt_count
after umount(2) has verified that victim is not busy, but before it
has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see
that it's safe to quietly undo mnt_count increment and leaves dropping
the reference to caller, where it'll be a full-blown mntput().
Check under mount_lock is needed; leaving the current one done before
taking that makes no sense - it's nowhere near common enough to bother
with.
Analysis and contextual insights are available on OpenCVE Cloud.
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
| Source | ID | Title |
|---|---|---|
Debian DLA |
DLA-4327-1 | linux security update |
Debian DLA |
DLA-4328-1 | linux-6.1 security update |
Debian DSA |
DSA-5973-1 | linux security update |
EUVD |
EUVD-2025-18595 | In the Linux kernel, the following vulnerability has been resolved: __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock ... or we risk stealing final mntput from sync umount - raising mnt_count after umount(2) has verified that victim is not busy, but before it has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see that it's safe to quietly undo mnt_count increment and leaves dropping the reference to caller, where it'll be a full-blown mntput(). Check under mount_lock is needed; leaving the current one done before taking that makes no sense - it's nowhere near common enough to bother with. |
Ubuntu USN |
USN-7704-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7704-2 | Linux kernel (FIPS) vulnerabilities |
Ubuntu USN |
USN-7704-3 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7704-4 | Linux kernel (NVIDIA) vulnerabilities |
Ubuntu USN |
USN-7704-5 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7711-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7712-1 | Linux kernel (Azure FIPS) vulnerabilities |
Ubuntu USN |
USN-7712-2 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7769-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7769-2 | Linux kernel (Real-time) vulnerabilities |
Ubuntu USN |
USN-7769-3 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7770-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7771-1 | Linux kernel (OEM) vulnerabilities |
Ubuntu USN |
USN-7789-1 | Linux kernel (Oracle) vulnerabilities |
Ubuntu USN |
USN-7789-2 | Linux kernel (Raspberry Pi) vulnerabilities |
Ubuntu USN |
USN-8028-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8028-2 | Linux kernel (Real-time) vulnerabilities |
Ubuntu USN |
USN-8031-1 | Linux kernel (GCP) vulnerabilities |
Ubuntu USN |
USN-8028-3 | Linux kernel (Real-time) vulnerabilities |
Ubuntu USN |
USN-8028-4 | Linux kernel (FIPS) vulnerabilities |
Ubuntu USN |
USN-8028-5 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8031-2 | Linux kernel (GCP FIPS) vulnerabilities |
Ubuntu USN |
USN-8028-6 | Linux kernel (HWE) vulnerabilities |
Ubuntu USN |
USN-8031-3 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8052-1 | Linux kernel (Low Latency) vulnerabilities |
Ubuntu USN |
USN-8028-7 | Linux kernel (Low Latency NVIDIA) vulnerabilities |
Ubuntu USN |
USN-8028-8 | Linux kernel (IBM) vulnerabilities |
Ubuntu USN |
USN-8052-2 | Linux kernel (Xilinx) vulnerabilities |
Ubuntu USN |
USN-8074-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-8074-2 | Linux kernel (Azure FIPS) vulnerabilities |
Ubuntu USN |
USN-8126-1 | Linux kernel (Azure) vulnerabilities |
Tue, 12 May 2026 13:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Thu, 18 Dec 2025 21:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Debian
Debian debian Linux |
|
| Weaknesses | CWE-667 | |
| CPEs | cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.15:rc1:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.15:rc2:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.15:rc3:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.15:rc4:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.15:rc5:*:*:*:*:*:* |
|
| Vendors & Products |
Debian
Debian debian Linux |
|
| Metrics |
cvssV3_1
|
cvssV3_1
|
Mon, 03 Nov 2025 18:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Fri, 20 Jun 2025 23:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Wed, 18 Jun 2025 09:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | In the Linux kernel, the following vulnerability has been resolved: __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock ... or we risk stealing final mntput from sync umount - raising mnt_count after umount(2) has verified that victim is not busy, but before it has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see that it's safe to quietly undo mnt_count increment and leaves dropping the reference to caller, where it'll be a full-blown mntput(). Check under mount_lock is needed; leaving the current one done before taking that makes no sense - it's nowhere near common enough to bother with. | |
| Title | __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock | |
| References |
|
|
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2026-05-12T12:04:23.226Z
Reserved: 2025-04-16T04:51:23.979Z
Link: CVE-2025-38058
No data.
Status : Modified
Published: 2025-06-18T10:15:38.590
Modified: 2026-05-12T13:16:41.707
Link: CVE-2025-38058
OpenCVE Enrichment
Updated: 2025-06-23T08:53:48Z
Debian DLA
Debian DSA
EUVD
Ubuntu USN