CVE-2026-93201 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
dm-pcache: validate seg_id fields from persistent memory
cache_pos_decode(), cache_key_decode() and the last-kset branches of cache_replay(), the writeback worker and the GC worker take a cache segment id from the cache device metadata and index cache->segments[]
with it without checking it against cache->n_segs. That metadata is only CRC-protected with a fixed public seed, so whoever supplies the cache device on a table load (CAP_SYS_ADMIN) controls the id; an out-of-range value forms a wild pcache_cache_segment pointer that is dereferenced and written through -- an out-of-bounds read and write driven by on-disk data.
Add cache_seg_id_valid() and reject an out-of-range id at each decode site, failing the operation with -EIO instead of indexing past the array. Bound the id against the initialized-segment count (cache_info.n_segs) rather than the physical device total. A forged cache_info.n_segs below seg_num otherwise leaves segments[cache_info.n_segs..seg_num) as zeroed
structs whose data pointer is NULL, so a forged id in that window would still be dereferenced. A later patch guarantees cache_info.n_segs <= seg_num, and a driver-created cache sets the two equal, so valid images are unaffected.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel's device-mapper persistent memory caching subsystem contains a critical out-of-bounds access vulnerability within its metadata decoding logic. Specifically, functions such as cache_pos_decode(), cache_key_decode(), and specific branches of cache_replay() along with the writeback and garbage collection workers retrieve segment identifiers from on-disk cache device metadata. These identifiers are subsequently used to index into the kernel's internal segments array without performing any bounds checking against the total number of valid segments, denoted as cache->n_segs. This lack of validation allows an attacker who controls the input data for a table load operation to trigger invalid memory accesses. Although the on-disk metadata is protected by CRC checks using a fixed public seed, this integrity mechanism only ensures that the data has not been corrupted during storage or transmission; it does not validate whether the content itself is semantically valid or safe for processing. Consequently, an entity with CAP_SYS_ADMIN privileges can supply crafted cache device images containing maliciously constructed segment identifiers to exploit this flaw.
The operational impact of this vulnerability involves both out-of-bounds reads and writes driven by on-disk data. When a forged segment identifier exceeds the bounds of the initialized segments array, it results in a wild pointer being dereferenced. This leads to memory corruption that can destabilize the kernel or potentially allow for arbitrary code execution depending on the specific memory layout and what resides at the out-of-bounds location. The vulnerability is particularly severe because it relies on data-driven exploitation where the attacker controls the index value through persistent storage rather than network input, making detection more difficult. Furthermore, a secondary issue exists regarding forged cache_info.n_segs values that are lower than the actual segment count. In such cases, segments within the range of the forged n_segs to the actual seg_num remain as zeroed structs with NULL data pointers. If an attacker supplies a segment identifier falling within this specific window, the system will attempt to dereference these null pointers, leading to kernel panics or further exploitation vectors related to null pointer dereferences.
To mitigate this vulnerability, developers have implemented strict validation logic by introducing the cache_seg_id_valid() function. This check is integrated at every site where segment identifiers are decoded from metadata, ensuring that any out-of-range identifier causes the operation to fail with an -EIO error code rather than proceeding with invalid indexing. The validation bounds the identifier against the initialized-segment count stored in cache_info.n_segs rather than the physical device total, which provides a more accurate representation of accessible memory structures. Additionally, subsequent patches ensure that cache_info.n_segs is always less than or equal to seg_num, and driver-created caches set these two values equally. This structural guarantee ensures that valid images remain unaffected while effectively closing the window for exploitation through forged metadata. The fix aligns with CWE-125 (Out-of-bounds Read) and CWE-787 (Out-of-bounds Write), addressing fundamental input validation failures in kernel subsystems handling persistent storage formats. From a threat modeling perspective, this vulnerability relates to ATT&CK techniques involving local privilege escalation through exploitation of memory corruption flaws within system administration tools.