CVE-2026-93201: dm-pcache: validate seg_id fields from persistent memory

Published Sep 17, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

dm-pcache: validate segid fields from persistent memory

cacheposdecode(), cachekeydecode() and the last-kset branches of cachereplay(), 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->nsegs. That metadata is only CRC-protected with a fixed public seed, so whoever supplies the cache device on a table load (CAPSYSADMIN) controls the id; an out-of-range value forms a wild pcachecachesegment pointer that is dereferenced and written through -- an out-of-bounds read and write driven by on-disk data.

Add cachesegidvalid() 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 (cacheinfo.nsegs) rather than the physical device total. A forged cacheinfo.nsegs below segnum otherwise leaves segments[cacheinfo.nsegs..segnum) as zeroed structs whose data pointer is NULL, so a forged id in that window would still be dereferenced. A later patch guarantees cacheinfo.nsegs <= segnum, and a driver-created cache sets the two equal, so valid images are unaffected.

Affected Software

1 affected component
kernel Linux kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Implement dm-pcache changes to validate seg_id fields from persistent memory. Bound the decoded id against cache_info.n_segs (initialized-segment count) and reject out-of-range ids using cache_seg_id_valid() at each decode, so invalid images fail the operation with -EIO instead of indexing past cache->segments[].

    dm-pcache seg_id validation = Add cache_seg_id_valid() and reject an out-of-range id at each decode; validate seg_id fields from persistent memory against cache_info.n_segs (initialized-segment count) rather than the physical device total; fail with -EIO on invalid id
  2. Compensating control

    If applicable to your deployment, ensure CAP_SYS_ADMIN (cache device table load permissions) is restricted, since id validation is related to how dm-pcache cache devices are created/loaded.

Event History

Sep 17, 2026
CVE Published
via MITRE·04:12 PM
Data Sourced
via MITRE·04:12 PM
Description

Frequently Asked Questions

1

Who can realistically exploit this issue?

An attacker needs CAP_SYS_ADMIN and the ability to supply the cache device when loading a device-mapper table. They can control the persistent-memory cache metadata containing the segment ID.

2

Does the metadata CRC prevent malicious segment IDs?

No. The metadata is CRC-protected with a fixed public seed, so a party supplying the cache device can forge metadata with an out-of-range segment ID.

3

What is the impact of a forged segment ID?

An out-of-range ID can be used to index past cache->segments[], producing a wild segment pointer. The kernel can then perform out-of-bounds reads and writes driven by on-disk metadata.

4

How does the resolved behavior handle invalid metadata?

The resolved code validates IDs against the initialized segment count, cache_info.n_segs, before indexing the segment array. Invalid IDs cause the affected operation to fail with -EIO.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203