CVE-2026-80961

What it actually does

In the Linux kernel dm-pcache target, kset key_num and per-key intra-segment offset/length are taken from on-media cache metadata after only a magic check and a fixed, public CRC seed. An oversized key_num makes cache_kset_crc(), cache_replay(), writeback, and GC walk past the kset key buffer (PCACHE_KSET_KEYS_MAX). A key whose offset plus length exceeds the segment data_size is still inserted into the cache tree, so later CRC checks and read hits copy adjacent persistent memory into the caller bio. The result is kernel out-of-bounds reads, cache-tree corruption, and disclosure of neighboring persistent-memory contents to userspace. Integrity and availability are also at risk if corrupted keys or over-reads destabilize cache workers or the kernel. The attacker must be able to supply the cache device (typically CAP_SYS_ADMIN).

Why it matters to the business

Hosts that use device-mapper persistent cache can leak data from persistent memory to a local user and may crash or corrupt the cache layer, affecting confidentiality of cached data and host stability. Risk is concentrated where dm-pcache is actually enabled and where less-trusted operators can attach cache media; organizations that never load this target have negligible exposure. Twenty days after publication, EPSS remains about 0.0017 with no 30-day increase, exploit maturity is none, and the issue is not in CISA KEV and is not associated with ransomware, so this is not an emergency mass-patch event unless dm-pcache is in production with untrusted backing devices.

How an attack unfolds

A local attacker who can present a persistent cache device to dm-pcache crafts on-media ksets so that key_num exceeds the in-memory key array and/or individual keys run past their segment. Because the CRC seed is public and only magic plus that CRC are checked first, the kernel accepts the device and then walks the unbounded fields during replay, writeback, or garbage collection, reading past the kset buffer. Overrunning keys are replayed into the cache tree; subsequent hits copy adjacent persistent memory into bios the attacker can read, leaking data to userspace. The same malformed metadata can disrupt cache workers. No remote unauthenticated path is described; control of the cache device and local privilege sufficient to attach it are required.

How to fix it

Apply the upstream Linux kernel change that adds kset_onmedia_valid() to bound key_num before any kset read and that rejects keys whose offset plus length, computed in 64-bit arithmetic, exceeds the segment data_size. Upgrade to a distribution kernel that includes this dm-pcache bounds validation. Valid metadata is unaffected. If a patched kernel is not yet available, do not attach untrusted cache devices, disable or avoid dm-pcache, and restrict CAP_SYS_ADMIN and device-mapper target creation so only trusted operators can supply pcache media.

How to confirm the fix worked

Confirm the running kernel includes the dm-pcache kset_onmedia_valid() check and the 64-bit intra-segment offset+length comparison against segment data_size (kernel changelog, distro advisory, or source/config of the installed build). Inventory systems for pcache device-mapper targets. After upgrading, verify legitimate pcache volumes still come online and serve I/O, and that malformed kset metadata is rejected rather than replayed. Review whether any cache backing devices are writable by untrusted parties.

Typical attack path

1. Obtain local access on a Linux system that uses or can load dm-pcache
2. Obtain the ability to supply or replace the pcache backing device (typically device-mapper administration / CAP_SYS_ADMIN)
3. Present crafted on-media kset metadata with out-of-range key_num and/or keys whose offset plus length exceed segment data_size
4. Trigger cache replay, writeback, or GC so the kernel decodes the unbounded fields
5. Read through cache hits (or observe worker failure) to obtain leaked adjacent persistent-memory contents or to disrupt the cache/kernel

How to detect it

No public exploit, named threat actor, or ransomware campaign is associated with this issue. To assess whether it was already abused, find hosts that loaded dm-pcache and accepted a cache device, then review kernel logs (dmesg, journalctl -k, crash dumps) for oops/BUG traces in cache_replay, cache_key_decode, cache_kset_crc, writeback, or GC around the time a pcache target was created or a cache device was replaced. Inspect device-mapper events for pcache table loads by unexpected users. Forensically, on-media ksets with key_num above the maximum key count or keys whose offset plus length exceed segment data_size indicate crafted metadata was presented. Correlate with local use of device-mapper administration. Absence of those artifacts does not prove non-exploitation if logging was insufficient.

• cache_replay
• cache_key_decode
• cache_kset_crc
• dm-pcache
• target: pcache
• PCACHE_KSET_KEYS_MAX

What your security team should do

• Patch Linux kernels that ship dm-pcache to a build containing kset key_num and intra-segment bounds validation
• Inventory device-mapper for pcache targets and treat unused dm-pcache as out of scope for emergency rollout
• Restrict CAP_SYS_ADMIN and device-mapper table loads so untrusted admins cannot attach cache devices
• Do not use untrusted or multi-writer persistent-memory/block devices as pcache backing stores
• Monitor kernel logs for dm-pcache replay/CRC anomalies and oopses in cache replay, key decode, writeback, or GC
• Prioritize by actual dm-pcache deployment; low EPSS, no KEV, and no known exploits do not justify organization-wide kernel emergencies on hosts that never load this target