Re: [PATCH 10/13] mm/migrate_device: refuse to migrate shadow stacks

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Critical] mm: out-of-bounds write in migrate_vma_setup() [1]
--

commit a0bf8430c5e68cd904038ab8081c7bc9a9b0f7de
Author: Chris Mason <mason@kernel.org>

mm/migrate_device: refuse to migrate shadow stacks

This commit rejects VMA device migration in migrate_vma_setup() when the VMA
has VMA_SHADOW_STACK set.

> diff --git a/mm/migrate_device.c b/mm/migrate_device.c
> index 0f2a2832e0bd1..c27f513ee46e3 100644
> --- a/mm/migrate_device.c
> +++ b/mm/migrate_device.c
> @@ -759,6 +759,8 @@ int migrate_vma_setup(struct migrate_vma *args)
>  	/* The migrate_vma page walk has no hugetlb support. */
>  	if (!vma_is_mm_backed(vma) || vma_is_hugetlb(vma) || vma_is_dax(vma))
>  		return -EINVAL;
> +	if (vma_test_single_mask(vma, VMA_SHADOW_STACK))
> +		return -EINVAL;
>  	if (nr_pages <= 0)
>  		return -EINVAL;
>  	if (args->start < vma->vm_start || args->start >= vma->vm_end)

[Severity: Critical]
This problem wasn't introduced by this patch, but can migrate_vma_setup()
write out of bounds on args->src and args->dst when given unaligned
addresses [1]?

mm/migrate_device.c:migrate_vma_setup() {
	const struct vm_area_struct *vma = args->vma;
	long nr_pages = (args->end - args->start) >> PAGE_SHIFT;

	args->start &= PAGE_MASK;
	args->end &= PAGE_MASK;
    ...
}

nr_pages is computed before args->start and args->end are masked with
PAGE_MASK.  For example, if args->start is 0x1fff and args->end is 0x3001,
nr_pages is 1, but masking rounds the range to [0x1000, 0x3000), which spans
2 pages.  When migrate_vma_collect() walks the aligned range, it writes past
the end of the caller's args->src and args->dst arrays.

[1] https://sashiko.dev/#/bug/linux-ca91ac03-4056-4cf8-8afb-0e516e08797f

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261111-mason-migrate-et-al-fixes-v1-0-3d2454362e8d@kernel.org?part=10