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 <[email protected]> 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/[email protected]?part=1
