CVE-2025-38058

What it actually does

Race condition in __legitimize_mnt() where the check for MNT_SYNC_UMOUNT is performed outside mount_lock, allowing a window where mnt_count can be incremented after umount(2) has verified a non-busy mount but before setting the flag, resulting in the reference drop being deferred to a full mntput() in the caller context instead of being silently undone.

Why it matters to the business

Local users on affected Linux kernel versions can trigger kernel instability or crashes during concurrent mount and unmount operations, increasing operational risk for systems running unpatched kernels; the large number of downstream Linux distributions and embedded devices amplifies exposure across server and appliance fleets.

How an attack unfolds

An attacker with local access races a carefully timed umount operation against another process performing mount-related activity, exploiting the unprotected MNT_SYNC_UMOUNT check to force an extra mntput() that the kernel is not prepared to handle safely, potentially leading to use-after-free or reference counting errors.

How to fix it

Upgrade the Linux kernel to a version containing commit 628fb00195ce21a90cf9e4e3d105cd9e58f77b40 or later; rebuild and reboot with the patched kernel; organizations using distribution packages should apply the vendor update that backports this fix.

How to confirm the fix worked

Verify the running kernel contains commit 628fb00195ce21a90cf9e4e3d105cd9e58f77b40 by checking /proc/version or the kernel build configuration; recompile a test kernel with the prior vulnerable code and confirm the race window is closed under concurrent mount/umount workloads.

Typical attack path

1. Obtain local user access on a vulnerable Linux system
2. Identify or create a mount point that can be concurrently manipulated
3. Trigger parallel umount(2) and mount-related syscalls to win the race window before mount_lock protects the MNT_SYNC_UMOUNT flag
4. Force the kernel to perform an unexpected mntput() that escalates the reference handling error

How to detect it

Review kernel logs for unexpected mntput() warnings, reference count mismatches, or mount-related oops during periods of concurrent mount activity; correlate with audit logs of umount syscalls from non-root users.

What your security team should do

• Prioritize kernel updates on all internet-facing and multi-user systems within standard patch windows
• Monitor upstream stable kernel releases for any follow-on fixes related to mount locking
• Limit unprivileged local access where feasible until patches are deployed