CVE-2026-93198: dm-pcache: validate the persisted dirty_tail chain at load
In the Linux kernel, the following vulnerability has been resolved:
dm-pcache: validate the persisted dirtytail chain at load
The writeback worker follows the persisted dirtytail chain, which is decoded from the cache device independently of the keytail chain that cachereplay() walks and bounds. A crafted image, whose on-media fields are authenticated only by a crc32c with a fixed seed, can aim dirtytail at a chain of last ksets that never terminates, so cachewritebackfn() re-arms itself with no delay forever.
Walk the dirtytail chain once at load with the same hop cap cachereplay() uses and fail the table load with -EIO if it does not reach an end within nsegs hops.
Affected Software
Event History
Frequently Asked Questions
What does an attacker need to exploit this issue?
An attacker needs to provide or cause use of a crafted dm-pcache cache-device image. The malformed persisted metadata can set dirty_tail to a non-terminating chain of last ksets.
What is the operational impact of a malicious cache image?
The writeback worker can repeatedly re-arm itself with no delay while following the non-terminating dirty_tail chain. This can result in an indefinitely running writeback worker.
How does the fix prevent exploitation?
The fixed code walks the persisted dirty_tail chain once during table load, using the same hop cap as cache_replay(). If the chain does not terminate within n_segs hops, the table load fails with -EIO.
How can administrators tell whether a cache image is rejected by the fix?
A dm-pcache table load will fail with -EIO when the persisted dirty_tail chain does not reach an end within n_segs hops.