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.
Metrics
Affected Vendors & Products
References
History
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: 2025-06-18T09:33:38.022Z
Updated: 2025-06-18T09:33:38.022Z
Reserved: 2025-04-16T04:51:23.979Z
Link: CVE-2025-38058
No data.
Status : Awaiting Analysis
Published: 2025-06-18T10:15:38.590
Modified: 2025-06-18T13:46:52.973
Link: CVE-2025-38058