CVE-2026-80958

What it actually does

Linux kernel dm-pcache performs an out-of-bounds read when a tail kset sits near the end of a cache segment. cache_replay(), the writeback worker, and the GC worker bound the read by the raw segment size (PCACHE_SEG_SIZE minus offset) instead of the data-region remainder (cache_seg_remain()), so the read continues into the following control/metadata area. A local low-privileged user who can exercise dm-pcache may disclose kernel memory from that control area and/or fault the kernel (availability impact). Integrity is not directly writable; this is a read overrun, not a write.

Why it matters to the business

Hosts that actually use dm-pcache can leak kernel memory or crash, interrupting storage I/O and any services on the box. Exploitation needs local access and the pcache target, so internet-only exposure is limited unless chained with another bug. EPSS is very low (~0.0016 and flat over 30 days), the issue is not in CISA KEV, ransomware use is not reported, and exploit maturity is none about 20 days after publication. Residual risk is highest on multi-tenant or shared kernels where kernel-memory disclosure aids later privilege escalation; blast radius is otherwise bounded because dm-pcache is a specialized device-mapper feature, not a default path on most servers.

How an attack unfolds

An attacker with an existing local, low-privileged foothold on a Linux system where dm-pcache is loaded waits for or induces cache replay, writeback, or garbage collection that processes a tail kset near a segment boundary. The kernel miscalculates remaining length and reads past segment data into the adjacent control area. The attacker may obtain leaked kernel metadata useful for defeating mitigations, or cause the kernel to consume invalid control bytes and oops/panic. No public exploit, named threat actor, or KEV-listed campaign is associated with this CVE; successful use would be a local information-disclosure or denial-of-service primitive, not remote code execution by itself.

How to fix it

Deploy a Linux kernel that includes the dm-pcache fix clamping tail-kset reads to cache_seg_remain() (the segment data region) in cache_replay, writeback, and GC. Prefer distribution/vendor kernel packages once they absorb the upstream change; rebuild custom kernels from a tree that contains that clamp. This record does not list exact package versions, so track vendor advisories for the patched kernel ABI. If dm-pcache is unused, disable the target, unload the module, and denylist it until patched. Limit device-mapper administration to trusted operators so untrusted users cannot configure pcache volumes.

How to confirm the fix worked

Confirm the running kernel changelog or source includes the clamp of tail-kset reads to cache_seg_remain() in the dm-pcache replay, writeback, and GC paths, and that the booted package matches a patched build. On hosts that should not use the feature, verify the pcache/dm-pcache module is not loaded and that no device-mapper table references pcache. Review package-manager and reboot logs to ensure the new kernel was actually booted. Do not attempt to reproduce the overrun.

Typical attack path

1. Gain local access to a Linux host that has dm-pcache configured or loadable
2. Identify device-mapper persistent-cache volumes and activity that will run replay, writeback, or GC
3. Cause those maintenance paths to process a tail kset near the end of a segment
4. Trigger the oversized tail-kset read into the following control area
5. Harvest leaked kernel memory for follow-on local escalation, or induce a kernel fault for denial of service

How to detect it

Information disclosure may leave little evidence if the kernel did not fault. Review dmesg, journald/kern.log, kdump/vmcore, and pstore for oops/panic stacks involving dm-pcache, pcache, cache_replay, writeback, or GC around and after the publication date. Look for unexpected pcache module loads, device-mapper table changes that add a pcache target, and sudden reboots outside change windows; correlate with local interactive or service-account activity. Absence of oopses does not prove the leak was unused. No public exploit tooling, ransomware markers, or named-actor TTPs are documented for this CVE.

• dm-pcache
• module pcache
• cache_replay
• pcache_
• Call Trace: and pcache in the same oops
• device-mapper table type pcache

What your security team should do

• Inventory where dm-pcache/pcache is loaded or referenced in device-mapper tables and patch those kernels first
• Apply vendor kernel updates containing the cache_seg_remain() clamp; do not wait for KEV listing given C:H kernel-memory disclosure
• Denylist and unload pcache/dm-pcache on systems that do not need persistent cache
• Restrict device-mapper and CAP_SYS_ADMIN-equivalent rights so untrusted local users cannot configure pcache
• Hunt kernel logs and crash dumps since publication for pcache-related oops/panic stacks
• Treat residual risk as moderate-urgent on multi-tenant hosts and low-urgent elsewhere given EPSS ~0.0016, no KEV, and no known exploits