CVE-2026-80959

What it actually does

The Linux kernel dm-pcache path decodes persisted key_tail and dirty_tail segment offsets in cache_pos_decode() and uses them to address within a cache segment without requiring the offset to be strictly below the segment data_size. A seg_off at or past data_size therefore reads past the segment data into adjacent kernel memory (out-of-bounds read / memory corruption class). The out-of-range offsets come from the cache device itself, so a crafted device can induce kernel information disclosure and, given High CIA scoring, follow-on integrity or availability impact (oops, panic, or further corruption) in the same kernel address space.

Why it matters to the business

Hosts that use device-mapper persistent cache can be crashed or have kernel memory exposed by a local actor who can supply the cache device, interrupting workloads on that machine and risking further local compromise. This is not a remote wormable issue: attack complexity is local, public exploit maturity is none, CISA KEV is false (no ransomware KEV association), and EPSS is very low and flat (~0.0017 over 30 days). Treat it as a standard high-severity local kernel fix—especially on systems that attach pcache devices—rather than an emergency internet-facing incident. No per-product fixed-version list was supplied, so operational urgency tracks your kernel vendor’s advisory and whether dm-pcache is in use.

How an attack unfolds

An attacker with local access who can present or influence a dm-pcache cache device (the issue is described as controllable by whoever supplies the device, typically involving CAP_SYS_ADMIN) persists key_tail and dirty_tail values that decode to a segment offset at or beyond the segment data_size. When the kernel later decodes those positions—on attach, recovery, or I/O through the pcache target—cache_pos_decode() indexes past the segment data and reads kernel memory it should not. The attacker observes leaked contents or a kernel fault and may try to chain that into denial of service or broader local privilege impact. No named threat actors, KEV campaigns, or public exploit code are associated with this CVE.

How to fix it

Apply the upstream Linux kernel change that rejects a decoded seg_off that is not below the segment data_size in dm-pcache cache_pos_decode(), via your distribution’s patched kernel package, then reboot or otherwise reload the kernel as the vendor requires. No exact per-package fixed versions were provided in this record—use the vendor advisory that maps this CVE to a kernel RPM/DEB/image. Until patched: do not attach untrusted cache devices or import pcache metadata from untrusted storage; restrict CAP_SYS_ADMIN and dmsetup to trusted administrators; unload or blacklist dm-pcache if persistent cache is unused.

How to confirm the fix worked

Confirm the running kernel changelog or vendor advisory includes the dm-pcache bound on persisted tail-position offsets (reject decoded seg_off not below data_size). Inventory whether dm-pcache is loaded (lsmod/sysfs module list) and whether any device-mapper table uses a pcache target. After installing the patched kernel, reboot as required and verify uname -r matches the patched package. Spot-check that legitimate pcache devices still assemble and that untrusted or out-of-range metadata is no longer accepted without a kernel oops.

Typical attack path

1. Obtain local access on a Linux system that uses or can be configured to use dm-pcache
2. Gain the ability to supply or control the cache device (typically CAP_SYS_ADMIN / device-mapper administration)
3. Place persisted key_tail and dirty_tail values whose decoded seg_off is at or past the segment data_size
4. Cause the kernel to decode those positions (pcache attach, cache recovery, or I/O)
5. Trigger an out-of-bounds read past segment data in kernel memory
6. Abuse the resulting disclosure or kernel instability for local information leak, crash, or further privilege impact

How to detect it

There is no public exploit and no named actor activity, so hunt for local triggering rather than network C2. Review dmesg, journalctl -k, /var/log/kern.log, and kdump/vmcore for oops, BUG, KASAN, or paging-request reports whose stack includes dm-pcache or cache_pos_decode, especially around device-mapper table loads. Audit for CAP_SYS_ADMIN use, dmsetup activity, and loading of the dm_pcache module; inspect mapper tables for pcache targets and whether the cache device appeared from unexpected removable or newly attached storage. A crash dump with cache_pos_decode on the stack is the strongest artifact that the unbounded offset was exercised.

• dm-pcache
• dm_pcache
• cache_pos_decode
• device-mapper: pcache
• /sys/module/dm_pcache

What your security team should do

• Inventory Linux fleets for dm-pcache / device-mapper persistent cache usage and patch those hosts first
• Deploy vendor kernels that include the cache_pos_decode seg_off bounds check as soon as packages exist; reboot into the new kernel
• Restrict CAP_SYS_ADMIN, raw cache-device access, and dmsetup to a minimal admin set
• Block attaching pcache backing devices or metadata from untrusted or newly introduced storage until patched
• Hunt kernel logs and crash dumps for dm-pcache / cache_pos_decode faults; EPSS is low and KEV is false, so run this as a planned high-severity kernel update rather than a KEV emergency