Answer in brief
CVE-2025-38058 records a Unknown severity vulnerability in __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Siemens/SIMATIC S7-1500 CPU 1518-4 PN/DP MFP (generic), Siemens/SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP (generic) and additional mapped packages. Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic), Siemens/SIMATIC S7-1500 CPU 1518-4 PN/DP MFP (generic), Siemens/SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP (generic) and additional mapped packages. Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=48a066e72d970a3e225a9c18690d570c736fc455 <628fb00195ce21a90cf9e4e3d105cd9e58f77b40 || >=48a066e72d970a3e225a9c18690d570c736fc455 <b89eb56a378b7b2c1176787fc228d0a57172bdd5 || >=48a066e72d970a3e225a9c18690d570c736fc455 <f6d45fd92f62845cbd1eb5128fd8f0ed7d0c5a42 || >=48a066e72d970a3e225a9c18690d570c736fc455 <9b0915e72b3cf52474dcee0b24a2f99d93e604a3 || >=48a066e72d970a3e225a9c18690d570c736fc455 <d8ece4ced3b051e656c77180df2e69e19e24edc1 || >=48a066e72d970a3e225a9c18690d570c736fc455 <8cafd7266fa02e0863bacbf872fe635c0b9725eb || >=48a066e72d970a3e225a9c18690d570c736fc455 <b55996939c71a3e1a38f3cdc6a8859797efc9083 || >=48a066e72d970a3e225a9c18690d570c736fc455 <250cf3693060a5f803c5f1ddc082bb06b16112a9 | 628fb00195ce21a90cf9e4e3d105cd9e58f77b40, b89eb56a378b7b2c1176787fc228d0a57172bdd5, f6d45fd92f62845cbd1eb5128fd8f0ed7d0c5a42, 9b0915e72b3cf52474dcee0b24a2f99d93e604a3, d8ece4ced3b051e656c77180df2e69e19e24edc1, 8cafd7266fa02e0863bacbf872fe635c0b9725eb, b55996939c71a3e1a38f3cdc6a8859797efc9083, 250cf3693060a5f803c5f1ddc082bb06b16112a9 |
| Linux/Linuxgeneric | 3.13 | Not reported |
| Siemens/SIMATIC S7-1500 CPU 1518-4 PN/DP MFPgeneric | >=V3.1.5 <* | * |
| Siemens/SIMATIC S7-1500 CPU 1518F-4 PN/DP MFPgeneric | >=V3.1.5 <* | * |
| Siemens/SIPLUS S7-1500 CPU 1518-4 PN/DP MFPgeneric | >=V3.1.5 <* | * |
Published upstream
Jun 18, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.