diff options
| author | Bryam Vargas <hexlabsecurity@proton.me> | 2026-07-17 06:26:54 -0500 |
|---|---|---|
| committer | Mikulas Patocka <mpatocka@redhat.com> | 2026-07-17 21:39:57 +0200 |
| commit | 90c990a68460d7b5720e5634cf650eccdf0f4098 (patch) | |
| tree | bc0b1c8e71dd94e0f3ac2543a669877294c000ea /tools/perf/scripts/python/bin | |
| parent | 22eb919f1b7900e2af0e952b1f1bee522f612b4a (diff) | |
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.
Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Diffstat (limited to 'tools/perf/scripts/python/bin')
0 files changed, 0 insertions, 0 deletions
