Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] On 32-bit architectures, passing a size >= 4GB to __alloc_contig_try_harder() causes silent truncation in rounddown_pow_of_two(), leading to an underflow in the order calculation and a subsequent massive out-of-bounds array access. -- --- Patch [1]: [PATCH v2] gpu/buddy: bail out of try_harder when alignment cannot be honoured --- commit bd00afca04077e9aca5c8cacc93b25007c5cb352 Author: Arunpravin Paneer Selvam <[email protected]> gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback is updated to realign a range whose start offset does not match min_block_size. It frees the misaligned run and reallocates at the next lower boundary to maintain the requested size. > diff --git a/drivers/gpu/buddy.c b/drivers/gpu/buddy.c > --- 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 is a pre-existing issue, but can this lead to an out-of-bounds array access on 32-bit architectures? In __alloc_contig_try_harder(), size is a u64. If a contiguous block of 4GB (0x100000000) or larger is requested, rounddown_pow_of_two(size) delegates to __rounddown_pow_of_two(unsigned long n), which silently truncates the 64-bit size to 32 bits on 32-bit architectures. For exactly 4GB, the truncated value becomes 0. Because ilog2(0) evaluates to -1, the order calculation underflows, producing a large positive value in the unsigned int order variable. When this underflowed order is subsequently used to index into the free trees further down in this function: root = &mm->free_trees[tree][order]; Would this result in an out-of-bounds memory read and a potential crash? > if (order == 0) > return -ENOSPC; > -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
