CVE-2026-80961

The Linux kernel's dm-pcache device-mapper target fails to validate two fields decoded from a persistent-memory cache device: the kset key_num, which is unbounded against the PCACHE_KSET_KEYS_MAX buffer, and each key's intra-segment offset and length, which are taken verbatim and can run past the segment's data_size. An attacker with CAP_SYS_ADMIN who supplies a crafted cache device can exploit the fact that only a magic value and a fixed public-seed CRC are checked first, causing out-of-bounds reads during kset replay and inserting bogus keys into the cache tree. Subsequent data-CRC checks and read hits then copy adjacent persistent-memory contents into the caller's bio, disclosing kernel/pmem memory to user space, and the same unvalidated fields drive the writeback and garbage-collection workers. Because triggering requires local access and the privilege to attach a cache device, this is mainly a sandbox/container escape or malicious-device scenario rather than a remote attack, and valid metadata is unaffected by the fix. No public proof of concept or in-the-wild exploitation is known.

What to do: Update to a kernel build containing the fix, which adds kset_onmedia_valid() to bound key_num before any kset read and rejects keys whose 64-bit offset-plus-length exceeds the segment data_size. Until patched, restrict CAP_SYS_ADMIN and device-mapper setup privileges so untrusted users or containers cannot attach arbitrary cache devices, and only bring up dm-pcache with cache devices from trusted sources. Hosts not using dm-pcache need no action beyond routine kernel patching.