CVE-2026-80961
UnknownSummary
In the Linux kernel, the dm-pcache module does not bound the kset key_num field or intra-segment bounds. key_num drives cache_kset_crc() and the replay loop in cache_replay(), and since only magic and a fixed-seed CRC are checked, an invalid key_num can read past the PCACHE_KSET_KEYS_MAX buffer. Additionally, a key's offset and length in cache_key_decode() are taken verbatim, allowing reads past the segment and leaking data to user space. The fix adds validation of key_num and key bounds.
Risk Assessment
A user with CAP_SYS_ADMIN privileges supplying the cache device can trigger out-of-bounds reads and leak kernel memory data to user space. This may lead to disclosure of sensitive information.
Recommendation
Update the Linux kernel to a version containing the dm-pcache module fix. Restrict the ability to load dm-pcache tables to trusted administrators.
Other vulnerabilities in Linux kernel (dm-pcache)
See all- CVE-2026-80962Unknown
In the Linux kernel, the dm-pcache module does not validate geometry fields (n_segs and segment id) from on-disk cache_info metadata. cache_segs_init() iterates n_segs times, indexing cache->segments[] sized to the device geometry. Since metadata is only CRC-protected with a public seed, whoever supplies the cache device (CAP_SYS_ADMIN) can provide an oversized n_segs or out-of-range id, causing out-of-bounds read and write. The fix rejects invalid values before use.
- CVE-2026-80960Unknown
In the Linux kernel, the dm-pcache module does not validate the seg_num field from the crc32c-only superblock. seg_num sizes cache->segments[] and bounds all later segment ids, but is never checked against the device. Whoever supplies the cache device (CAP_SYS_ADMIN) can provide an oversized seg_num, causing an out-of-bounds write (12 KiB memset) into kernel memory at table load. The fix rejects seg_num that is zero, larger than the device can hold, or larger than PCACHE_CACHE_SEGS_MAX.
- CVE-2026-80959Unknown
In the Linux kernel, the dm-pcache module does not bound the seg_off offset in cache_pos_decode(), which takes persisted key_tail and dirty_tail values from the cache device. A seg_off at or past the segment data_size, controllable by whoever supplies the device (CAP_SYS_ADMIN), reads past the segment data. The fix rejects a decoded seg_off that is not below the segment data_size.
- CVE-2026-80958Unknown
In the Linux kernel, the dm-pcache module in cache_replay(), the writeback worker, and the GC worker bounds the tail-kset read length by PCACHE_SEG_SIZE - seg_off, the raw segment size rather than the data region. A tail near the segment end reads past the segment data into the following control area. The fix clamps the read to cache_seg_remain(), the data region.
- CVE-2026-80957Unknown
In the Linux kernel, the dm-pcache module in cache_replay() follows the on-media last-kset chain via next_cache_seg_id without cond_resched(). A forged chain pointing back to an already visited segment causes the replay loop to run forever. The fix caps the last-kset hops at cache->n_segs, since a valid chain visits each segment at most once.
- CVE-2026-80956Unknown
In the Linux kernel, the dm-pcache module's get_cache_segment() scans the segment map up to cache->n_segs (physical device segment count), but cache_segs_init() only initializes the first cache_info->n_segs segments. A crafted image with a smaller cache_info->n_segs leaves the remaining pcache_cache_segment structs zeroed (segment.data == NULL), and the allocator can hand one to cache_kset_close(), which writes through the data pointer without a NULL check. The fix bounds the allocator's search to cache_info->n_segs.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: dm-pcache: validate kset key_num and intra-segment bounds Two more fields decoded from the cache device go unbounded. The kset key_num drives cache_kset_crc() and the replay loop in cache_replay(), the writeback worker and the GC worker, but only the magic and a fixed-seed CRC are checked first, so a non-last kset whose key_num exceeds the PCACHE_KSET_KEYS_MAX buffer reads past its end before the CRC compare. A key's intra-segment offset and length in cache_key_decode() are taken verbatim, so a key running past its segment is replayed into the cache tree and the data CRC check and every later read hit then copy adjacent persistent memory into the caller's bio -- an out-of-bounds read that leaks to user space. Both fields are controlled by whoever supplies the cache device (CAP_SYS_ADMIN); the CRC seed is public. Add kset_onmedia_valid() to bound key_num before any kset read, and reject a key whose offset plus length, computed in 64 bits, exceeds the segment data_size. Valid metadata is unaffected.