CVE-2026-80962
UnknownSummary
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.
Risk Assessment
The vulnerability allows a user with CAP_SYS_ADMIN privileges (supplying the cache device) to read and write out of bounds in kernel memory, potentially leading to privilege escalation or system corruption. Exploitation requires high privileges.
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-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-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 geometry fields from on-disk cache_info cache_segs_init() iterates cache_info->n_segs times indexing cache->segments[], which is sized to the cache device geometry, and get_seg_id() takes each segment id from the on-media cache_info and the per-segment next_seg link. Both come from cache device metadata that is only CRC-protected with a fixed public seed, so whoever supplies the cache device on a table load (CAP_SYS_ADMIN) controls them: an oversized n_segs or an out-of-range id drives an out-of-bounds access of cache->segments[] and a wild CACHE_DEV_SEGMENT() pointer into the device mapping -- an out-of-bounds read and write from on-disk data. Reject an n_segs that exceeds the device segment count and a segment id that is out of range before either is used. Valid metadata is unaffected.