CVE-2026-80957

What it actually does

Linux kernel dm-pcache cache_replay() walks the on-media last-kset chain via next_cache_seg_id with neither a hop bound nor cond_resched(). A cyclic chain makes replay run forever on the activating CPU, hanging cache bring-up and potentially the host (availability/DoS, not memory corruption or privilege escalation).

Why it matters to the business

Hosts that use device-mapper persistent cache can freeze during boot, resume, or cache replay, taking storage offline until reboot and a kernel update. Exposure is limited to systems actually using dm-pcache. Exploitation likelihood is currently low: EPSS about 0.002 with a flat 30-day trend, not listed in CISA KEV, not associated with ransomware, and exploit maturity is none. The issue was published about 20 days ago; treat as a targeted availability risk rather than a mass-exploitation emergency.

How an attack unfolds

An attacker who can supply or alter dm-pcache on-media metadata (malicious or tampered cache backing device, image, or local writes to cache segments) forges a last-kset chain that points back to an already-visited segment. When the kernel activates or recovers the cache, cache_replay() follows next_cache_seg_id indefinitely and never yields, denying service. No public weaponization, named threat actors, or ransomware use is indicated.

How to fix it

Upgrade the Linux kernel to a build that includes the dm-pcache fix: cap last-kset hops during replay at cache->n_segs so a valid chain visits each segment at most once. Use your distribution’s patched stable kernel when vendor packages exist. Until patched, do not attach, import, or replay dm-pcache volumes from untrusted media, and limit who can create or bind pcache backing devices. No specific upstream version numbers were provided with this record—confirm the hop-cap change in your kernel changelog.

How to confirm the fix worked

Verify the running kernel changelog or source contains the dm-pcache last-kset cycle detection (hop limit at n_segs in cache_replay). After updating, activate known-good pcache devices and confirm replay finishes and the device becomes ready. Review dmesg/journal for a clean pcache replay with no hung-task or soft-lockup traces. Do not validate by loading crafted cyclic metadata.

Typical attack path

1. Gain the ability to present or modify dm-pcache on-media metadata (untrusted cache device, image, or local write to cache segments).
2. Forge a last-kset chain that cycles via next_cache_seg_id.
3. Trigger cache activation or replay (boot, device resume, or dm setup of pcache).
4. Replay walks the cycle without bound or reschedule, hanging the CPU/thread and blocking cache/storage availability.

How to detect it

This is an in-kernel hang, not a remote implant. Search kernel logs (dmesg, journald, crash dumps, hung_task/soft-lockup reports) for stacks in cache_replay or dm-pcache around cache device activation, boot, or resume. Correlate lockups with attaching or importing a pcache backing device. There are no known campaigns or actor-specific artifacts. A reboot after a hang may erase live evidence; inspect persistent journal and vmcore if available. Lack of lockups does not prove the path was never exercised.

• cache_replay
• dm-pcache
• next_cache_seg_id
• last-kset
• hung_task: blocked for more than
• watchdog: BUG: soft lockup

What your security team should do

• Inventory where dm-pcache / device-mapper persistent cache is in use and patch those kernels first.
• Apply distribution or upstream kernels that cap last-kset hops during replay.
• Until patched, block activation of pcache from untrusted or externally supplied backing devices.
• Watch kernel hung-task and soft-lockup alerts whose stacks mention cache_replay or dm-pcache.
• Track vendor advisories until a fixed kernel for each deployed major/stable line is confirmed.