CVE-2026-80960

What it actually does

The Linux kernel dm-pcache target trusted an attacker-controlled on-media superblock field (seg_num) without checking it against the cache device size or hard limits. That value sizes cache->segments[] and bounds later on-media segment IDs. Because the cache device is a direct pmem map, an out-of-range segment ID resolves past the mapping into ordinary kernel memory; new-cache init then calls cache_seg_init() -> cache_dev_zero_range() and memset()s 12 KiB over that memory—an out-of-bounds write into the kernel heap at device-mapper table load. A zero seg_num yields ZERO_SIZE_PTR allocations. The result is kernel heap corruption with likely oops/panic and, depending on layout, possible further kernel integrity or privilege impact. Table load requires CAP_SYS_ADMIN.

Why it matters to the business

Only Linux hosts that actually load the dm-pcache (persistent-memory cache) device-mapper target are in scope; that is an uncommon configuration, so blast radius is limited. A local actor who already has administrator-equivalent capability to load device-mapper tables can crash the host or corrupt kernel memory, causing outages or, in a worst case, deeper compromise of the machine. The issue is not in CISA KEV, is not associated with ransomware, has no public exploit, and EPSS is very low and unchanged (~0.002 over 30 days). Treat as a high-priority local kernel-memory-corruption patch where pcache is in production; otherwise fold into the normal vendor kernel cadence rather than emergency change windows.

How an attack unfolds

An attacker who already holds CAP_SYS_ADMIN prepares a persistent-memory cache device whose crc32c-only superblock encodes a seg_num that is zero, larger than the device can hold, or larger than PCACHE_CACHE_SEGS_MAX. They load a device-mapper table that instantiates the pcache target against that device. The kernel uses the unvalidated seg_num to size segment arrays and to interpret on-media segment IDs; IDs past the pmem mapping are treated as pointers into kernel heap. During new-cache initialization the kernel writes a 12 KiB zero range through that pointer, corrupting adjacent heap. No public exploit, named threat actor, or in-the-wild campaign is associated with this issue about 20 days after publication.

How to fix it

Apply the vendor or distribution kernel update that includes the dm-pcache fix: reject seg_num that is zero, larger than the cache device can hold, or larger than PCACHE_CACHE_SEGS_MAX before it is used to size arrays or bound on-media IDs. Exact package versions were not supplied with this record—use your distro’s advisory for the kernel that contains this change and reboot into it. Until patched, do not load dm-pcache against untrusted or user-supplied pmem/cache images; restrict device-mapper table load (CAP_SYS_ADMIN / root) to trusted operators; and consider blacklisting or not building the pcache target where it is unused.

How to confirm the fix worked

Confirm the running kernel changelog or stable commit includes dm-pcache superblock seg_num validation against device size and PCACHE_CACHE_SEGS_MAX. Inventory exposure with kernel config (pcache/dm-pcache built-in or module), lsmod, and device-mapper table listings for a pcache target. After patching, a table load against a cache device with zero or oversized seg_num should fail closed (rejected table load) rather than oops. Regression-test only with owned lab images; do not replay malformed superblocks on production hosts.

Typical attack path

1. Obtain local CAP_SYS_ADMIN (compromised privileged process, overly permissive container, or malicious administrator).
2. Supply a crafted persistent-memory cache device whose superblock contains an invalid seg_num.
3. Load a device-mapper table that instantiates the pcache target against that device.
4. Kernel maps segment IDs past the pmem mapping and performs a 12 KiB out-of-bounds heap write during cache segment init.
5. Resulting heap corruption is used to crash the host or attempt further kernel compromise.

How to detect it

This is a local table-load memory corruption, not a network worm: look for evidence that a pcache mapping was loaded and that the kernel faulted in dm-pcache init paths. Review kernel logs (journald/kmsg/dmesg archives) around device-mapper table loads for oops/panic stacks mentioning cache_seg_init, cache_dev_zero_range, dm-pcache, or a paging/NULL-deref after a pcache table load. Check audit or sudo logs for privileged dmsetup/ioctl activity creating a pcache target, and inspect whether unusual pmem or cache images were attached shortly before a crash. There are no known campaign hashes, C2 indicators, or threat-actor TTPs for this CVE.

• cache_seg_init
• cache_dev_zero_range
• dm-pcache
• target type pcache
• PCACHE_CACHE_SEGS
• Unable to handle kernel paging request
• Kernel panic - not syncing
• ZERO_SIZE_PTR
• dmsetup create
• DM_TABLE_LOAD

What your security team should do

• Identify hosts that build or load dm-pcache and prioritize those for the vendor kernel update and reboot.
• Until patched, prevent loading pcache against untrusted cache devices and tighten who may load device-mapper tables.
• Watch kernel logs for pcache-related oopses around table load (cache_seg_init / cache_dev_zero_range) as a sign of attempted or accidental trigger.
• Do not treat this as a mass internet-facing emergency: EPSS is low, KEV is false, exploit maturity is none; still patch pcache production systems promptly because it is kernel heap corruption.
• Track distro kernel advisories for the exact fixed package and verify post-reboot that the vulnerable module/target is no longer present.