CVE-2026-80957
UnknownSummary
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.
Risk Assessment
A user with CAP_SYS_ADMIN privileges supplying a crafted cache device can trigger an infinite loop in the kernel, leading to system hang (DoS).
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-80961Unknown
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.
- 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-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: detect a cycle in the last-kset chain during replay cache_replay() follows the on-media last-kset chain by next_cache_seg_id with no cond_resched(). A forged chain that points back into a segment it has already visited makes the replay loop follow it forever. Cap the last-kset hops at cache->n_segs; a valid chain visits each segment at most once.