Re: [PATCH v2] gpu/buddy: bail out of try_harder when alignment cannot be honoured

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Integer truncation in `rounddown_pow_of_two(size)` on 32-bit architectures leads to out-of-bounds array access.
--

--- Patch [1]: [PATCH v2] gpu/buddy: bail out of try_harder when alignment cannot be honoured ---
commit e9f823b96a2660e1690b65d2c8c95099338dc996
Author: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>

gpu/buddy: bail out of try_harder when alignment cannot be honoured

The try_harder contiguous fallback could return a range whose start
offset did not match the caller's min_block_size. When a candidate's
start is misaligned, realign it: free the misaligned run and reallocate
exactly @size at the next lower min_block_size boundary.

> diff --git a/drivers/gpu/buddy.c b/drivers/gpu/buddy.c
> index dc81fe0301ce8..3c73ae87f3c5b 100644
> --- a/drivers/gpu/buddy.c
> +++ b/drivers/gpu/buddy.c

[ ... ]

>  static int __alloc_contig_try_harder(struct gpu_buddy *mm,
>  				     u64 size,
>  				     u64 min_block_size,
>  				     struct list_head *blocks)
>  {
> -	u64 rhs_offset, lhs_offset, lhs_size, filled;
> +	u64 rhs_offset, lhs_offset, filled;
>  	struct gpu_buddy_block *block;
>  	unsigned int tree, order;
> -	LIST_HEAD(blocks_lhs);
> -	unsigned long pages;
>  	u64 modify_size;
>  	int err;
>  
>  	modify_size = rounddown_pow_of_two(size);
> -	pages = modify_size >> ilog2(mm->chunk_size);
> -	order = fls(pages) - 1;
> +	order = ilog2(modify_size) - ilog2(mm->chunk_size);

[Severity: High]
This isn't a bug introduced by this patch, but could this integer truncation
lead to out-of-bounds array accesses on 32-bit architectures?

The size parameter is a u64, but the rounddown_pow_of_two() macro operates
on an unsigned long. On a 32-bit system, if a large size is passed
(e.g., 4GB) where the lower 32 bits are smaller than chunk_size or zero,
the truncation can result in modify_size becoming 0.

When modify_size is 0, ilog2(0) yields -1. This causes order (an unsigned
int) to underflow into a massive positive value. The if (order == 0) check
is bypassed, and this huge order value is then used to index into the
mm->free_trees[tree][order] array, which could crash the kernel during the
RB tree traversal.

>  	if (order == 0)
>  		return -ENOSPC;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709131050.1022759-1-Arunpravin.PaneerSelvam@amd.com?part=1