Answer in brief
CVE-2026-93198 records a Unknown severity vulnerability in dm-pcache: validate the persisted dirty_tail chain at load. The current sources do not mark it as known exploited. The current feed maps 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.
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). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=1d57628ff95b32d5cfa8d8f50e07690c161e9cf0 <8195cf3f4a82ef49d9b0651c507ed0784caf23fb || >=1d57628ff95b32d5cfa8d8f50e07690c161e9cf0 <4822a030929e0e77aa380722dc42e3e4c9edd346 || >=1d57628ff95b32d5cfa8d8f50e07690c161e9cf0 <58d620ee9e01d4bdbceaf2ae1450d307a2a9d58b | 8195cf3f4a82ef49d9b0651c507ed0784caf23fb, 4822a030929e0e77aa380722dc42e3e4c9edd346, 58d620ee9e01d4bdbceaf2ae1450d307a2a9d58b |
| Linux/Linuxgeneric | 6.18 | Not reported |
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 the persisted dirty_tail chain at load The writeback worker follows the persisted dirty_tail chain, which is decoded from the cache device independently of the key_tail chain that cache_replay() walks and bounds. A crafted image, whose on-media fields are authenticated only by a crc32c with a fixed seed, can aim dirty_tail at a chain of last ksets that never terminates, so cache_writeback_fn() re-arms itself with no delay forever. Walk the dirty_tail chain once at load with the same hop cap cache_replay() uses and fail the table load with -EIO if it does not reach an end within n_segs hops.
Quoted source text, attributed separately from HOL analysis.