CVE-2026-80956

What it actually does

dm-pcache's get_cache_segment() can return uninitialized pcache_cache_segment objects whose data pointer is NULL when a cache image advertises fewer initialized segments than the physical device segment count. cache_kset_close() then writes through that pointer with no NULL check, producing a kernel NULL-pointer write. On typical configurations this is a host oops/panic; if the zero page were writable it would be in-kernel memory corruption.

Why it matters to the business

Hosts that use Linux device-mapper persistent cache (dm-pcache) can be crashed by attaching a crafted cache image, causing unplanned downtime and possible data-path interruption for workloads on that cache. Exposure is limited to systems that actually load dm-pcache; the issue is not in CISA KEV, has no reported ransomware use, exploit maturity is none, and EPSS remains very low (~0.002) with no 30-day rise. Published about 20 days ago, so treat as a routine kernel patch rather than an emergency internet-facing incident unless dm-pcache is in production.

How an attack unfolds

An attacker who can present a pcache image (typically via privileged device-mapper setup or control of backing storage) crafts metadata so cache_info->n_segs is smaller than the device segment count. cache_segs_init() only initializes the first n_segs entries; the rest stay zeroed (segment.data == NULL). get_cache_segment() still scans up to cache->n_segs and can hand an uninitialized segment to cache_kset_close(), which writes through the NULL data pointer and oopses the kernel. No named threat actors or in-the-wild campaigns are associated with this issue.

How to fix it

Apply the upstream Linux kernel fix that bounds get_cache_segment() to cache_info->n_segs so only initialized segments are returned (commit message: “dm-pcache: only hand out initialized cache segments”). Upgrade to a distribution kernel that includes that change. Until patched, do not attach untrusted pcache images, restrict who can create device-mapper targets, and unload or disable dm-pcache if it is unused. Conforming caches already set n_segs equal to the device segment count, so the bound does not break legitimate images.

How to confirm the fix worked

Confirm the running kernel changelog or git history contains the dm-pcache fix that limits allocator search to cache_info->n_segs. After upgrade, verify dm-pcache still works with a conforming image (n_segs equal to device segment count) and that an image with undersized n_segs no longer yields a NULL data pointer or oops. Inventory hosts for loaded dm-pcache / device-mapper cache usage (lsmod, dmsetup table) to confirm residual exposure.

Typical attack path

1. Gain the ability to attach or supply a dm-pcache cache image (usually CAP_SYS_ADMIN / device-mapper, or control of the backing device)
2. Prepare a non-conforming image where cache_info->n_segs is less than the physical device segment count so trailing segment structs are never initialized
3. Cause the kernel to load that image so the allocator searches up to cache->n_segs
4. Induce a code path that consumes an uninitialized segment (cache_kset_close() writing through segment.data)
5. Trigger a kernel NULL-pointer write, resulting in oops/panic or, in rare zero-page-writable setups, further memory corruption

How to detect it

There are no public exploits or named actors; look for whether the bug was already triggered as a crash rather than a stealthy implant. Search kernel logs (dmesg, journalctl -k, /var/log/kern.log, crash dumps, kdump/vmcore) around dm-pcache attach/close for NULL-pointer dereference oopses whose call trace includes dm-pcache, get_cache_segment, cache_kset_close, or pcache_cache_segment. Correlate with recent device-mapper table loads (dmsetup history, audit of CAP_SYS_ADMIN / ioctl on /dev/mapper). Absence of those oopses does not prove the host was never exposed—only that this particular write-through-NULL path may not have fired.

• BUG: kernel NULL pointer dereference
• dm-pcache
• get_cache_segment
• cache_kset_close
• pcache_cache_segment
• cache_segs_init

What your security team should do

• Inventory which hosts load dm-pcache or otherwise use device-mapper persistent cache and prioritize those for kernel updates
• Deploy vendor/distro kernels that include the “only hand out initialized cache segments” dm-pcache fix
• Until patched, block untrusted cache images and restrict device-mapper configuration to trusted administrators
• If dm-pcache is unused, unload the module and prevent it from loading
• Watch kernel logs for dm-pcache NULL-pointer oopses; there is no KEV deadline or known active exploitation, so treat as standard kernel hygiene unless production cache hosts are unpatched