CVE-2025-38058
Linux Kernel ≤ 5.4.294
Raw vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HSummary
CVE-2025-38058 is a medium-severity Improper Locking (CWE-667) vulnerability in Linux Linux Kernel. Its CVSS base score is 5.5 (Medium).
Operationally, ranked at the 3th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SC-39 (Process Isolation) and SC-3 (Security Function Isolation) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-18595
Vulnerability Data
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,…
more
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.
- CWE(s)
Related Threats
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
Mitigating Controls (NIST 800-53 r5) AI
Directly enforces process isolation for kernel objects such as mount namespaces, preventing the exact race on mnt_count and MNT_SYNC_UMOUNT that the missing mount_lock check allows.
Requires isolation of security-critical kernel functions (VFS mount handling) so that reference-count operations cannot be observed or altered by concurrent unmount paths.
Protects in-kernel data structures (mount reference counts) from unauthorized concurrent modification, mitigating the window exploited by CVE-2025-38058.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly include code reviews, static analysis, and concurrency standards that prevent improper locking.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect race conditions and locking errors before release.
Secure development lifecycle includes concurrency and locking requirements that reduce improper locking defects.
Application security requirements can mandate proper lock acquisition/release patterns.
Secure architecture principles address thread-safety and resource synchronization.
Secure coding standards directly prohibit missing or incorrect lock usage.
Change management may catch locking issues introduced by modifications but does not prevent the weakness itself.