CVE-2026-80962

What it actually does

Untrusted on-disk dm-pcache cache_info geometry is consumed without bounds checks. cache_segs_init() iterates cache_info->n_segs against cache->segments[], and get_seg_id() follows on-media segment ids and next_seg links. Those fields are only CRC-protected with a fixed public seed, so a crafted cache device can supply an oversized n_segs or an out-of-range id. That produces an out-of-bounds index of cache->segments[] and a wild CACHE_DEV_SEGMENT() pointer into the device mapping, yielding kernel out-of-bounds read and write. The result is kernel memory corruption with possible information leak, panic/DoS, or further privilege escalation in the kernel. Valid metadata is unaffected by the intended fix.

Why it matters to the business

Hosts that load Linux device-mapper persistent cache (dm-pcache) can be crashed or have kernel integrity broken if a locally privileged operator attaches a crafted cache device. Confidentiality, integrity, and availability of the kernel are all at risk (CVSS 7.8). Exploitation is local, not remote, and typically requires the ability to supply the cache device on a table load (CAP_SYS_ADMIN), so blast radius is limited to machines that use dm-pcache and accept attacker-influenced storage. The issue is not in CISA KEV, is not associated with ransomware, has no published exploit maturity, and EPSS remains very low and flat (~0.0017 over 30 days). Residual business risk is therefore concentrated on Linux servers and appliances that still run an unpatched kernel and load untrusted cache devices, not on broad internet-facing exposure. Patch within normal kernel-update cycles; treat as higher urgency only where dm-pcache is in production or untrusted disks are routinely mapped.

How an attack unfolds

An attacker who already has local access and can influence the cache device presented at dm-pcache table load crafts on-disk cache_info so that n_segs exceeds the real device segment count and/or segment ids / next_seg links are out of range. The CRC uses a fixed public seed, so the metadata can be made to pass the existing integrity check. When a privileged process loads the pcache target, cache_segs_init() and get_seg_id() trust those fields, index off the end of cache->segments[], and compute a wild device-mapping pointer. The kernel then performs out-of-bounds reads and writes. Depending on layout, that can panic the host immediately or corrupt adjacent kernel state that a follow-on local exploit might turn into code execution or privilege gain. No named threat actors or in-the-wild campaigns are associated with this CVE, and exploit maturity is none.

How to fix it

Apply a Linux kernel update that includes the dm-pcache fix to validate geometry fields from on-disk cache_info: reject n_segs that exceeds the device segment count and reject out-of-range segment ids before they are used in cache_segs_init() or get_seg_id(). Rebuild and deploy any out-of-tree or vendor kernels that carry dm-pcache. If an exact distro package is not yet available, pull the corresponding stable-tree commit that adds those checks; valid metadata does not need migration. Until patched, do not load dm-pcache tables against untrusted or removable cache devices, restrict CAP_SYS_ADMIN and device-mapper table loads to tightly controlled admins, and consider blacklisting or not building the pcache target where the feature is unused. Reboot into the patched kernel so the running image actually contains the checks.

How to confirm the fix worked

Confirm the running kernel changelog or stable commit list includes the dm-pcache change that validates n_segs against the device segment count and rejects out-of-range segment ids before use. On each host, record uname -r, whether the pcache target is built (config and /lib/modules), and whether any device-mapper tables currently reference pcache. After upgrade and reboot, verify the new kernel is booted and that loading a well-formed pcache table still succeeds. Optionally, in a disposable lab only, present metadata with n_segs larger than the device geometry or an out-of-range segment id and confirm the table load is rejected rather than oopsing; do not perform that test on production. Inventory configuration management and image pipelines so custom kernels are rebuilt with the same fix.

Typical attack path

1. Obtain local access on a Linux host that uses or can be induced to use dm-pcache.
2. Prepare or substitute a cache device whose on-disk cache_info has an oversized n_segs and/or out-of-range segment identifiers (CRC still valid because the seed is public and fixed).
3. Cause a device-mapper table load of the pcache target against that device (typically requiring CAP_SYS_ADMIN).
4. Trigger cache_segs_init()/get_seg_id() so the kernel indexes cache->segments[] out of bounds and follows a wild CACHE_DEV_SEGMENT() pointer.
5. Use the resulting kernel out-of-bounds read/write to crash the host or corrupt kernel memory for further local privilege escalation.

How to detect it

This flaw leaves no unique network IOC; look for local kernel failures at dm-pcache table load. Collect dmesg, journalctl -k, /var/log/kern.log, crash dumps (kdump/vmcore), and systemd/audit records of device-mapper table loads around the time a pcache target was created. Search oops/panic reports for frames in cache_segs_init, get_seg_id, or other dm-pcache symbols, and for out-of-bounds or paging errors while a pcache table was being loaded. Correlate with privileged processes (CAP_SYS_ADMIN) that issued dmsetup/ioctl table loads against a new or swapped cache device, unexpected attach of removable or untrusted block devices, and subsequent host reboot or hang. Because metadata CRC uses a fixed public seed, a crafted device will not necessarily show CRC failure—absence of CRC errors does not mean the geometry was honest. No named APT or ransomware use is documented; treat hits as local abuse or accidental bad media unless other intrusion evidence exists.

• cache_segs_init
• get_seg_id
• dm-pcache
• target: pcache
• pcache_ctr
• CACHE_DEV_SEGMENT
• BUG: unable to handle kernel paging request
• Oops:
• Call Trace:
• dmsetup create
• DM_TABLE_LOAD
• CAP_SYS_ADMIN

What your security team should do

• Inventory Linux kernels and images for dm-pcache / CONFIG associated with the pcache device-mapper target and prioritize those hosts for kernel update and reboot.
• Treat unpatched dm-pcache as a local kernel-memory-corruption risk: restrict who can load device-mapper tables and who can attach cache devices until the patched kernel is running.
• Do not wait on KEV or EPSS; this is not listed in KEV and EPSS is low, but CVSS 7.8 with C/I/A high still warrants inclusion in the current kernel patch cycle (issue published ~20 days ago).
• Block or avoid mapping untrusted, multi-tenant, or removable storage as a pcache cache device on unpatched kernels.
• Add kernel-oops monitoring for pcache-related frames so a failed or malicious table load is visible even before patching.
• Track vendor/stable kernel advisories for the exact package version that carries the geometry validation fix and confirm it is deployed, not just staged.