All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <balbirs@nvidia.com>
To: Hui Su <sh_def@163.com>
Cc: akpm@linux-foundation.org, david@kernel.org, ziy@nvidia.com,
	 matthew.brost@intel.com, joshua.hahnjy@gmail.com,
	rakie.kim@sk.com, byungchul@sk.com,  gourry@gourry.net,
	ying.huang@linux.alibaba.com, apopple@nvidia.com,
	 linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/migrate_device: avoid out-of-bounds writes for compound folios
Date: Mon, 17 Aug 2026 18:18:34 +1000	[thread overview]
Message-ID: <aoLDQifuyIiO-2eA@parvat> (raw)
In-Reply-To: <20260817074350.442493-2-sh_def@163.com>

On Mon, Aug 17, 2026 at 03:43:51PM +0800, Hui Su wrote:
> migrate_device_range() and migrate_device_pfns() clear the entries
> following a compound folio so that the PFN arrays retain their
> page-granular representation.
> 
> If a compound folio extends beyond the end of the caller-provided range,
> the loops clear all following folio entries without limiting them to the
> number of slots remaining in the npages-sized array, causing an
> out-of-bounds write.
> 
> Limit the number of entries updated and consumed to the remaining array
> slots while keeping the actual number of pages in the folio unchanged.
> 
> Observed with a KASAN x86 QEMU kernel using the HMM
> migrate_anon_huge_zero selftest. Closing /dev/hmm_dmirror0 after
> migrating an anonymous huge page to device memory exercises:
> 
>   dmirror_fops_release()
>     -> dmirror_device_evict_chunk()
>       -> migrate_device_range()
> 
> Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
> Signed-off-by: Hui Su <sh_def@163.com>
> ---
>  mm/migrate_device.c | 16 +++++++++-------
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/mm/migrate_device.c b/mm/migrate_device.c
> index 908d2d4ec43a..67bfc1af0b29 100644
> --- a/mm/migrate_device.c
> +++ b/mm/migrate_device.c
> @@ -1396,16 +1396,17 @@ int migrate_device_range(unsigned long *src_pfns, unsigned long start,
>  	for (pfn = start, i = 0; i < npages; pfn++, i++) {
>  		struct page *page = pfn_to_page(pfn);
>  		struct folio *folio = page_folio(page);
> -		unsigned int nr = 1;
> +		unsigned long nr, slots;
>  
>  		src_pfns[i] = migrate_device_pfn_lock(pfn);
>  		nr = folio_nr_pages(folio);
> +		slots = min(nr, npages - i);
>  		if (nr > 1) {
>  			src_pfns[i] |= MIGRATE_PFN_COMPOUND;
> -			for (j = 1; j < nr; j++)
> +			for (j = 1; j < slots; j++)
>  				src_pfns[i+j] = 0;
> -			i += j - 1;
> -			pfn += j - 1;
> +			i += slots - 1;
> +			pfn += slots - 1;
>  		}
>  	}
>  
> @@ -1430,15 +1431,16 @@ int migrate_device_pfns(unsigned long *src_pfns, unsigned long npages)
>  	for (i = 0; i < npages; i++) {
>  		struct page *page = pfn_to_page(src_pfns[i]);
>  		struct folio *folio = page_folio(page);
> -		unsigned int nr = 1;
> +		unsigned long nr, slots;
>  
>  		src_pfns[i] = migrate_device_pfn_lock(src_pfns[i]);
>  		nr = folio_nr_pages(folio);
> +		slots = min(nr, npages - i);
>  		if (nr > 1) {
>  			src_pfns[i] |= MIGRATE_PFN_COMPOUND;
> -			for (j = 1; j < nr; j++)
> +			for (j = 1; j < slots; j++)
>  				src_pfns[i+j] = 0;
> -			i += j - 1;
> +			i += slots - 1;
>  		}
>  	}
>  
> -- 
> 2.54.0
> 
>

There is a similar fix sent out by Matthew, The question is, is it OK to
send in partial data upto npages (when nr > npages - i)? We should bail
early and not proceed if that is the case.

Balbir


      reply	other threads:[~2026-08-17  8:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-17  7:43 [PATCH] mm/migrate_device: avoid out-of-bounds writes for compound folios Hui Su
2026-08-17  8:18 ` Balbir Singh [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aoLDQifuyIiO-2eA@parvat \
    --to=balbirs@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=byungchul@sk.com \
    --cc=david@kernel.org \
    --cc=gourry@gourry.net \
    --cc=joshua.hahnjy@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matthew.brost@intel.com \
    --cc=rakie.kim@sk.com \
    --cc=sh_def@163.com \
    --cc=ying.huang@linux.alibaba.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.