Re: [PATCH v2 2/2] dm array: reject an array block whose value size is not the caller's

On Sat, Aug 1, 2026 at 6:55=E2=80=AFAM Bryam Vargas via B4 Relay
<[email protected]> wrote:
>
> From: Bryam Vargas <[email protected]>
>
> array_block_check() can only compare the header against itself, so a bloc=
k
> with value_size 4 and max_entries 1018 is internally consistent and passe=
s.
> dm-cache keeps two arrays -- mappings at 8 bytes and hints at 4 -- and th=
e
> roots for both live in the superblock. Point the mappings root at a hint
> block and __load_mappings() walks it through an info whose value size is =
8,
> so element_at() strides 8 bytes over 4-byte entries and reaches offset 81=
60
> of a 4096-byte block.
>
> get_ablock() and __shadow_ablock() are the two places that hold the block
> and the caller at once. Reject there when the two value sizes disagree.
> Arrays only ever read their own blocks, so this fires on crafted metadata
> only.
>
> Fixes: 6513c29f44f2 ("dm persistent data: add transactional array")
> Suggested-by: Ming-Hung Tsai <[email protected]>
> Cc: [email protected]
> Signed-off-by: Bryam Vargas <[email protected]>

Reviewed-by: Ming-Hung Tsai <[email protected]>

The fix addresses more than crafted metadata. A lost write on disk
drives can cause a stale block that was freed as a hint block,
triggering this out-of-bounds access issue.