CVE-2026-80961: dm-pcache: validate kset key_num and intra-segment bounds
In the Linux kernel, the following vulnerability has been resolved:
dm-pcache: validate kset keynum and intra-segment bounds
Two more fields decoded from the cache device go unbounded. The kset keynum drives cacheksetcrc() and the replay loop in cachereplay(), the writeback worker and the GC worker, but only the magic and a fixed-seed CRC are checked first, so a non-last kset whose keynum exceeds the PCACHEKSETKEYSMAX buffer reads past its end before the CRC compare. A key's intra-segment offset and length in cachekeydecode() are taken verbatim, so a key running past its segment is replayed into the cache tree and the data CRC check and every later read hit then copy adjacent persistent memory into the caller's bio -- an out-of-bounds read that leaks to user space. Both fields are controlled by whoever supplies the cache device (CAPSYSADMIN); the CRC seed is public.
Add ksetonmediavalid() to bound keynum before any kset read, and reject a key whose offset plus length, computed in 64 bits, exceeds the segment datasize. Valid metadata is unaffected.
Affected Software
Event History
Frequently Asked Questions
Who can realistically exploit this issue?
An attacker needs the ability to supply or control the dm-pcache cache device, which requires CAP_SYS_ADMIN. The affected metadata fields and the CRC seed are controlled or known to that party.
What can exploitation cause?
An oversized kset key_num can cause reads beyond the kset buffer before CRC validation. A key whose offset and length extend beyond its segment can cause adjacent persistent memory to be copied into a caller's bio, leaking data to user space.
How can I determine whether my cache metadata is malicious or malformed?
The vulnerable behavior is triggered when a non-last kset has key_num greater than PCACHE_KSET_KEYS_MAX, or when a decoded key's offset plus length exceeds the segment data_size. Existing validation of only the magic value and fixed-seed CRC does not prevent these cases.
What is the mitigation if the fix cannot be applied immediately?
Restrict CAP_SYS_ADMIN access and do not use cache devices supplied by untrusted administrative users. The vulnerable fields originate from the cache device metadata.