Answer in brief
CVE-2026-93201 records a High severity (CVSS 7.8) vulnerability in dm-pcache: validate seg_id fields from persistent memory. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. 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), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=1d57628ff95b32d5cfa8d8f50e07690c161e9cf0 <b4bf8af5e7d7db4c5e179e15017da55857761ac4 || >=1d57628ff95b32d5cfa8d8f50e07690c161e9cf0 <90c990a68460d7b5720e5634cf650eccdf0f4098 | b4bf8af5e7d7db4c5e179e15017da55857761ac4, 90c990a68460d7b5720e5634cf650eccdf0f4098 |
| Linux/Linuxgeneric | 6.18 | Not reported |
| Linux/Linuxgeneric | >=1d57628ff95b32d5cfa8d8f50e07690c161e9cf0 <96d4b275281b45aacd0f0510fa8bec85d9f7dc5a || >=1d57628ff95b32d5cfa8d8f50e07690c161e9cf0 <b4bf8af5e7d7db4c5e179e15017da55857761ac4 || >=1d57628ff95b32d5cfa8d8f50e07690c161e9cf0 <90c990a68460d7b5720e5634cf650eccdf0f4098 | 96d4b275281b45aacd0f0510fa8bec85d9f7dc5a, b4bf8af5e7d7db4c5e179e15017da55857761ac4, 90c990a68460d7b5720e5634cf650eccdf0f4098 |
Published upstream
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 17, 2026
In the Linux kernel, the following vulnerability has been resolved: dm-pcache: validate seg_id fields from persistent memory cache_pos_decode(), cache_key_decode() and the last-kset branches of cache_replay(), the writeback worker and the GC worker take a cache segment id from the cache device metadata and index cache->segments[] with it without checking it against cache->n_segs. That metadata is only CRC-protected with a fixed public seed, so whoever supplies the cache device on a table load (CAP_SYS_ADMIN) controls the id; an out-of-range value forms a wild pcache_cache_segment pointer that is dereferenced and written through -- an out-of-bounds read and write driven by on-disk data. Add cache_seg_id_valid() and reject an out-of-range id at each decode site, failing the operation with -EIO instead of indexing past the array. Bound the id against the initialized-segment count (cache_info.n_segs) rather than the physical device total. A forged cache_info.n_segs below seg_num otherwise leaves segments[cache_info.n_segs..seg_num) as zeroed structs whose data pointer is NULL, so a forged id in that window would still be dereferenced. A later patch guarantees cache_info.n_segs <= seg_num, and a driver-created cache sets the two equal, so valid images are unaffected.
Quoted source text, attributed separately from HOL analysis.