From: Balbir Singh <balbirs@nvidia.com>
To: Andrew Morton <akpm@linux-foundation.org>, Hui Su <sh_def@163.com>
Cc: 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, stable@vger.kernel.org
Subject: Re: [PATCH v2] mm/migrate_device: avoid out-of-bounds writes for compound folios
Date: Tue, 18 Aug 2026 21:13:25 +1000 [thread overview]
Message-ID: <f039fb9c-465f-479b-a909-2e57943d545a@nvidia.com> (raw)
In-Reply-To: <20260817112150.aa6cc927cf501d687336c0ef@linux-foundation.org>
On 8/18/26 4:21 AM, Andrew Morton wrote:
> On Mon, 17 Aug 2026 20:08:00 +0800 Hui Su <sh_def@163.com> 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.
>>
>> Do not proceed with a compound folio if its page-granular representation
>> does not fit entirely in the remaining PFN array. If this happens, drop
>> any reference and lock acquired for the folio, clear the remaining
>> entries, and stop collecting.
>>
>> 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()
>
> It isn't clear (to me, at least) what "exercises:" means. Was there a
> WARN? Did the kernel crash? Did it erase all my cat videos?
>
> IOW, in detail, what are the userspace-visible effects of the bug?
> Please add this info to the changelog and maintain it.
>
> Sashiko might have found some things. Some pre-existing, some newly added:
> https://sashiko.dev/#/patchset/20260817120758.669807-3-sh_def@163.com
>
>
userspace-visible effects are a function of the usage of the API by the device
driver. If the device driver passes in npages that don't account for PMD pages,
it would be an issue. In the case above, closing the device will evict pages
from the device back to the CPU, but I am surprised that the size of npages was
not properly split, we should fix that as well.
FYI: I've tried reading through Sashiko's report, but there is too much
pre-existing content that it points to and it can be quite time consuming. I am
working on adding new test cases to try and catch some of the issues found
Balbir
prev parent reply other threads:[~2026-08-18 11:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 12:08 [PATCH v2] mm/migrate_device: avoid out-of-bounds writes for compound folios Hui Su
2026-08-17 18:21 ` Andrew Morton
2026-08-18 11:13 ` 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=f039fb9c-465f-479b-a909-2e57943d545a@nvidia.com \
--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=stable@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox