20th Oct 2026
Preface: The primary purpose of dm-pcache is to resolve the storage I/O bottleneck in large-scale machine learning workflows (such as PyTorch DataLoader / DataPipe) or Large Language Model (LLM) training, where backend data agents (worker threads) frequently pull chunks of data from slower primary storage.
Background: The following instructions require the use of the accompanying infographics. In standard PyTorch training, multiple CPU worker threads (num_workers > 0) utilize the DataPipe to prefetch, decode, and organize the next batch of data before moving it into GPU VRAM.
In standard PyTorch training, multiple CPU worker threads (num_workers > 0) utilize the DataPipe to prefetch, decode, and organize the next batch of data before moving it into GPU VRAM.
• The Traditional Bottleneck: If your training dataset (consisting of hundreds of gigabytes of images, audio, or text tokens) is stored on standard NVMe SSDs or HDDs, concurrent random reads from multiple workers create severe I/O serialization and latency spikes. This results in GPU Starvation, where your expensive GPUs sit idle waiting for data.
• The dm-pcache Solution:
o The first time PyTorch requests a data block, dm-pcache fetches it from the slow backing storage and caches it directly into Persistent Memory (PMEM) / CXL with near-nanosecond latency.
o Since ML training runs across multiple epochs (repeatedly reading the exact same data), from the second epoch onward, when the backend DataPipe worker requests that data again, dm-pcache serves it instantly from the memory-tier cache layer.
Vulnerability details: CVE-2026-98867 – In the Linux kernel, the following vulnerability has been resolved: dm-pcache: bound the logical key offset from persistent memory cache_key_decode() takes a key’s logical off from the cache device and later indexes req_key_tree->subtrees[ ] by it in get_subtree(). An off past the device forms a subtree pointer outside the array, which rb_insert( ) writes through during replay. Reject a key of zero length, or whose off+len (computed in 64 bits) exceeds the device size, before it is used.
Before the patch, the driver used cache_key_decode() to extract a key’s logical offset and length directly from the persistent media layout.As detailed in step 4, the initial implementation lacked robust bounds checking. Because it did not calculate the boundary using proper 64-bit math, an attacker could forge a massive offset that causes an integer wrap-around. This tricks the kernel into bypassing device boundary checks, leading to a dangerous out-of-bounds write during index parsing.”
Official announcement: Please refer to the link for details –