Coverity: zblock_alloc(): Memory - illegal accesses

[coverity-bot]

Hello!

This is an experimental semi-automated report about issues detected by
Coverity from a scan of next-20221117 as part of the linux-next scan project:
https://scan.coverity.com/projects/linux-next-weekly-scan

You're getting this email because you were associated with the identified
lines of code (noted below) that were touched by commits:

  Wed Nov 16 16:19:12 2022 -0800
    9097e28c25c8 ("mm: add zblock - new allocator for use via zpool API")

Coverity reported the following:

*** CID 1527352:  Memory - illegal accesses  (OVERRUN)
mm/zblock.c:320 in zblock_alloc()
314     	}
315     	list = &(pool->block_lists[block_type]);
316
317     check:
318     	spin_lock(&list->lock);
319     	/* check if there are free slots in cache */
vvv     CID 1527352:  Memory - illegal accesses  (OVERRUN)
vvv     Overrunning array of 10208 bytes at byte offset 10208 by dereferencing pointer "list".
320     	block = cache_find_block(list);
321     	if (block)
322     		goto found;
323     	spin_unlock(&list->lock);
324
325     	/* not found block with free slots try to allocate new empty block */

If this is a false positive, please let us know so we can mark it as
such, or teach the Coverity rules to be smarter. If not, please make
sure fixes get into linux-next. :) For patches fixing this, please
include these lines (but double-check the "Fixes" first):

Reported-by: coverity-bot <keescook+coverity-bot@xxxxxxxxxxxx>
Addresses-Coverity-ID: 1527352 ("Memory - illegal accesses")
Fixes: 9097e28c25c8 ("mm: add zblock - new allocator for use via zpool API")

It looks like block_type is not checked to be < ARRAY_SIZE(block_desc)
after exiting the earlier loop, so the access through "list" may be past
the end of pool->block_lists.

Thanks for your attention!

-- 
Coverity-bot