CVE-2026-80960: dm-pcache: validate on-media seg_num against the cache device size
In the Linux kernel, the following vulnerability has been resolved:
dm-pcache: validate on-media segnum against the cache device size
segnum is read from the crc32c-only superblock, so whoever supplies the cache device on a table load (CAPSYSADMIN) controls it. It sizes cache->segments[] and is the value every later on-media segment id is bounded against, yet it is never checked against the device. Because cachedev->mapping is the direct map of the pmem, CACHEDEVSEGMENT() for a segment id past the device resolves to ordinary kernel memory beyond the mapping; a new-cache init reaching such an id has cacheseginit() -> cachedevzerorange() memset() 12 KiB over that memory -- an out-of-bounds write into the kernel heap at table load. A zero segnum makes the segment allocations ZEROSIZEPTR.
Reject a segnum that is zero, larger than the device can hold, or larger than PCACHECACHESEGSMAX before it is used.
Affected Software
Event History
Frequently Asked Questions
Who can trigger this issue?
An attacker needs CAP_SYS_ADMIN and must be able to supply a cache device when loading a device-mapper table. The vulnerable seg_num value is read from that cache device's CRC32C-only superblock.
What is the impact of a malicious cache-device superblock?
An oversized seg_num can cause initialization to resolve segment addresses beyond the direct-mapped persistent-memory device and perform a 12 KiB memset into kernel heap memory during table load. A zero seg_num can also cause segment allocations to use ZERO_SIZE_PTR.
What values should be rejected when assessing a fix or mitigation?
seg_num must be rejected before use if it is zero, exceeds the number of segments the cache device can hold, or exceeds PCACHE_CACHE_SEGS_MAX.