If we have no VMAs prior to us, such as in a case where we are mremap()'ing a VMA backwards, then we will advance the iterator backwards to 0, before moving to the original range again. The intent is to position the iterator at or before the gap, therefore we must avoid this - this is simply addressed by only advancing the iterator should vma_prev() yield a result. Reported-by: kernel test robot <oliver.sang@xxxxxxxxx> Closes: https://lore.kernel.org/oe-lkp/202408271452.c842a71d-lkp@xxxxxxxxx Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> --- mm/vma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/vma.c b/mm/vma.c index 8a5fa15f46a2..7d948edbbb9e 100644 --- a/mm/vma.c +++ b/mm/vma.c @@ -1557,8 +1557,8 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap, vmg.vma = NULL; /* New VMA range. */ vmg.pgoff = pgoff; vmg.next = vma_next(&vmi); - vma_prev(&vmi); - vma_iter_next_range(&vmi); + if (vma_prev(&vmi)) + vma_iter_next_range(&vmi); new_vma = vma_merge_new_range(&vmg); -- 2.46.0
