From: sashiko-bot@kernel.org
To: "Stanislav Kinsburskii" <skinsburskii@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3] drm/gpusvm: Zero HMM PFNs before scanning ranges
Date: Thu, 23 Jul 2026 18:10:43 +0000 [thread overview]
Message-ID: <20260723181045.9F6FC1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260723-drm-gpusvm-fixes-v3-1-4346a61d093a@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Medium] Incomplete fix: drm_gpusvm_scan_mm() still passes uninitialized memory to hmm_range_fault()
--
--- Patch [1]: [PATCH v3] drm/gpusvm: Zero HMM PFNs before scanning ranges ---
commit 94c866dacf02fc79cf17cd390ee14ceb8a723458
Author: Stanislav Kinsburskii <skinsburskii@gmail.com>
drm/gpusvm: Zero HMM PFNs before scanning ranges
This commit fixes an issue where drm_gpusvm_check_pages() passes an
uninitialized PFN array to HMM. It changes the allocation to use kvcalloc()
to ensure the array is zero-initialized before HMM scanning, which prevents
random memory contents from being interpreted as valid PFN flags.
> diff --git a/drivers/gpu/drm/drm_gpusvm.c b/drivers/gpu/drm/drm_gpusvm.c
> index fcfe635bc1956..736c3a3e28f80 100644
> --- a/drivers/gpu/drm/drm_gpusvm.c
> +++ b/drivers/gpu/drm/drm_gpusvm.c
> @@ -787,7 +787,7 @@ static bool drm_gpusvm_check_pages(struct drm_gpusvm *gpusvm,
>
> mmap_assert_locked(gpusvm->mm);
>
> - pfns = kvmalloc_array(npages, sizeof(*pfns), GFP_KERNEL);
> + pfns = kvcalloc(npages, sizeof(*pfns), GFP_KERNEL);
> if (!pfns)
> return false;
[Severity: Medium]
This isn't a bug introduced by this patch, but does the same fix need to be
applied to drm_gpusvm_scan_mm() in the same file?
drivers/gpu/drm/drm_gpusvm.c:drm_gpusvm_scan_mm() {
...
pfns = kvmalloc_array(npages, sizeof(*pfns), GFP_KERNEL);
if (!pfns)
return DRM_GPUSVM_SCAN_UNPOPULATED;
hmm_range.hmm_pfns = pfns;
...
}
It appears drm_gpusvm_scan_mm() also allocates the uninitialized PFN array
using kvmalloc_array() and passes it to hmm_range_fault() with default_flags
set to 0. It then reads pfns[i] to check HMM_PFN_VALID, leaving it
susceptible to the exact same uninitialized memory issue fixed here.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260723-drm-gpusvm-fixes-v3-1-4346a61d093a@gmail.com?part=1
next prev parent reply other threads:[~2026-07-23 18:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 17:49 [PATCH v3] drm/gpusvm: Zero HMM PFNs before scanning ranges Stanislav Kinsburskii
2026-07-23 18:10 ` sashiko-bot [this message]
2026-07-23 20:40 ` Matthew Brost
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=20260723181045.9F6FC1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=skinsburskii@gmail.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.