Re: [PATCH v3 06/21] md/md-llbitmap: allocate page controls independently

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Out-of-bounds array access in `llbitmap_write()` during bitmap resize due to omitted `BITMAP_DATA_OFFSET` in `llbitmap_reserved_pages()`.
--

--- Patch [6]: [PATCH v3 06/21] md/md-llbitmap: allocate page controls independently ---
commit f9c192fc9c795037298b0412c1ab2a50e3c88637
Author: Yu Kuai <yukuai@fygo.io>

md/md-llbitmap: allocate page controls independently

This commit modifies the allocation of llbitmap page controls to
allocate and free them individually. It also updates llbitmap_read_page()
to return a zeroed page when the index is beyond the current size,
preparing the code for in-place growth.

> diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
> index e3500a1a52c07..4c3fc4b35aff0 100644
> --- a/drivers/md/md-llbitmap.c
> +++ b/drivers/md/md-llbitmap.c

[ ... ]

> +static unsigned int llbitmap_reserved_pages(struct llbitmap *llbitmap)
> +{
> +	return DIV_ROUND_UP(llbitmap->mddev->bitmap_info.space << SECTOR_SHIFT,
> +			    PAGE_SIZE);
> +}

[Severity: High]
Does this calculation underestimate the maximum number of pages needed
for in-place growth by omitting BITMAP_DATA_OFFSET?

If an array is configured with a small initial capacity and a bitmap space
that is a multiple of PAGE_SIZE, llbitmap_alloc_pages() might allocate
the pctl array with too few pages because this function omits the offset.

If the array is later resized up to the maximum capacity allowed by the space,
would this cause an out-of-bounds access in llbitmap_write()?

llbitmap_write() calculates the page index as:

    pos += BITMAP_DATA_OFFSET;
    idx = pos >> PAGE_SHIFT;

    llbitmap->pctl[idx]->state[bit] = state;

If pos pushes idx beyond the under-allocated nr_pages, it looks like this
will result in an out-of-bounds array access.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1785206690.git.yukuai@fygo.io?part=6