CVE-2026-80955

What it actually does

A use-after-free in the Linux kernel dm-pcache kset_replay() path occurs when a cache key with a stale segment generation (key->seg_gen older than the live cache segment generation) is released with cache_key_put() and then immediately dereferenced via key->cache_pos.cache_seg as an argument to cache_seg_get(). The same path also sets cache segment-map bits and takes segment references for expired invalid keys whose backing data is no longer valid. The result is kernel-memory corruption that can panic the host or, if freed mempool memory is reused, enable further kernel-object corruption with High impact on confidentiality, integrity, and availability. The flaw is local (AV:L), requires only low privileges (PR:L), and needs no user interaction.

Why it matters to the business

Linux hosts that use device-mapper persistent cache can suffer unexpected kernel crashes and storage or application outages, or in a worst case a local privilege-escalation that fully compromises the machine. The issue is not a remote, unauthenticated network attack: an adversary already needs a local low-privileged account. Exploitation likelihood is currently low (EPSS about 0.17% and flat over 30 days, not listed in CISA KEV, no ransomware use, exploit maturity None), but the High 7.8 CVSS rating still makes unpatched shared, multi-tenant, or developer Linux systems an operational risk. The vulnerability was disclosed about 20 days ago, so patch windows should already be in progress.

How an attack unfolds

An adversary who already has local, low-privileged execution on a system with dm-pcache loaded induces kset_replay() to process cache keys whose segment generation is stale. The vulnerable sequence frees the key and then continues to use that object for cache_seg_get() and may also mark invalid segments in the cache segment map. If the mempool recycles the freed memory, subsequent kernel operations run against a dangling pointer, which can crash the kernel or, with additional heap shaping, be turned into elevated privileges. No public exploit, named threat-actor campaign, or in-the-wild use is reported.

How to fix it

Apply a Linux kernel update that includes the dm-pcache kset_replay() fix: cache_seg_get() and __set_bit() must run only after the generation check, and expired/invalid keys must be skipped (continue) rather than released and then reused. Prefer vendor or distro kernels that explicitly list this CVE or the corresponding dm-pcache commit. If dm-pcache is not required, do not load the module and blacklist it to shrink exposure until patched. Reboot into the patched kernel; there is no reliable userspace workaround for this in-kernel UAF. Confirm the running kernel package after reboot.

How to confirm the fix worked

Verify the installed and running kernel changelog, advisory, or git commit contains the dm-pcache kset_replay() generation-check reorder (cache_seg_get()/__set_bit() after the stale-gen test, continue on invalid keys). Compare uname -r and the distro kernel package version against the vendor advisory. Confirm whether dm-pcache is loaded (lsmod) or referenced in device-mapper tables; systems that never load it are not practically exposed. After patching, reboot and re-check the running kernel, and watch dmesg/journal for absence of new dm-pcache oopses during cache replay.

Typical attack path

1. Obtain local low-privileged access on a Linux host where dm-pcache is in use
2. Cause dm-pcache to hold cache keys whose segment generation is stale relative to the live cache segment
3. Trigger kset_replay() so cache_key_put() runs and the freed key is still used for cache_seg_get() and segment-map updates
4. Convert the resulting use-after-free into a kernel oops/panic or, if allocator reuse is influenced, into higher privileges
5. Abuse kernel or root context for persistence, data access, or further movement on the host

How to detect it

There are no public exploits, so look for crash evidence rather than a known payload. Collect kernel logs (dmesg, journalctl -k, /var/log/kern.log, crash dumps, kdump/vmcore, and cloud serial consoles) around dm-pcache replay activity. Search oops/panic traces for dm-pcache, kset_replay, cache_key_put, cache_seg_get, and use-after-free or paging-request reports in those frames. Note module load of dm-pcache and device-mapper table changes that enable persistent cache. Correlate any such crash with local logins, sudo, or container breakout attempts on the same host. Absence of these logs does not prove the bug was never hit; it only means a noisy crash was not recorded.

• kset_replay
• dm-pcache
• cache_key_put
• cache_seg_get
• Unable to handle kernel paging request
• use-after-free
• BUG: kernel NULL pointer dereference
• Call Trace:.*dm_pcache
• pcache

What your security team should do

• Patch and reboot Linux kernels to a build that includes the dm-pcache kset_replay() UAF fix as the primary control
• Inventory hosts that load dm-pcache or use device-mapper persistent cache and prioritize those for the kernel update
• If dm-pcache is unused, blacklist the module until kernels are patched
• Treat remaining unpatched multi-tenant or shared Linux servers as higher priority despite low EPSS and non-KEV status because of local High C/I/A impact
• Hunt kernel logs for historical dm-pcache/kset_replay oopses around the disclosure window, then close the ticket only after the patched kernel is confirmed running