intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sebastian Brzezinka" <sebastian.brzezinka@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/selftests: Fix unlocked mm.stolen in reset selftest
Date: Fri, 21 Aug 2026 13:48:21 +0000	[thread overview]
Message-ID: <20260821134821.6FCA21F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260821134044.15908-1-sebastian.brzezinka@intel.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [Medium] The logic to determine if a stolen page is unused evaluates to always false, neutralizing the selftest.
- [Medium] Missing lock protection when accessing the globally shared `ggtt->error_capture` memory, risking arbitrary memory corruption.
- [Medium] Time-of-Check to Time-of-Use (TOCTOU) race condition between checking page availability and poisoning it.
--

--- Patch [1]: [PATCH] drm/i915/selftests: Fix unlocked mm.stolen in reset selftest ---
commit eab33f79c43e7ed3d420674fa2faede0152e1b0b
Author: Sebastian Brzezinka <sebastian.brzezinka@intel.com>

drm/i915/selftests: Fix unlocked mm.stolen in reset selftest

This commit fixes an unlocked access to i915->mm.stolen in the reset selftest
by wrapping __drm_mm_interval_first() calls with i915->mm.stolen_lock. This
prevents a NULL pointer dereference observed during igt_reset_device_stolen().

Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16841

> diff --git a/drivers/gpu/drm/i915/gt/selftest_reset.c b/drivers/gpu/drm/i915/gt/selftest_reset.c
> index 2cfc23c58e909..eb6b2261329da 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_reset.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_reset.c

[ ... ]

> @@ -95,9 +96,12 @@ __igt_reset_stolen(struct intel_gt *gt,
>  		dma_addr_t dma = (dma_addr_t)dsm->start + (page << PAGE_SHIFT);
>  		void __iomem *s;
>  		void *in;
>  
>  		ggtt->vm.insert_page(&ggtt->vm, dma,
>  				     ggtt->error_capture.start,
>  				     i915_gem_get_pat_index(gt->i915,
>  							    I915_CACHE_NONE),
>  				     0);

[Severity: Medium]
This is a pre-existing issue, but does this code modify the globally shared
ggtt->error_capture memory without serialization?

If a real GPU error occurs or sysfs is accessed concurrently during test
execution, could the error capture PTE be overwritten, risking arbitrary
memory corruption?

>  		mb();
>  
>  		s = io_mapping_map_wc(&ggtt->iomap,
>  				      ggtt->error_capture.start,
>  				      PAGE_SIZE);
>  
> -		if (!__drm_mm_interval_first(&gt->i915->mm.stolen,
> -					     page << PAGE_SHIFT,
> -					     ((page + 1) << PAGE_SHIFT) - 1))
> +		mutex_lock(&gt->i915->mm.stolen_lock);
> +		unused = !__drm_mm_interval_first(&gt->i915->mm.stolen,
> +						  page << PAGE_SHIFT,
> +						  ((page + 1) << PAGE_SHIFT) - 1);

[Severity: Medium]
This is a pre-existing issue, but does this logic to determine if a stolen
page is unused evaluate to always false?

Looking at __drm_mm_interval_first(), it returns &mm->head_node when no
interval is found, which is a non-NULL pointer. This means
!__drm_mm_interval_first(...) is always false.

Does this neutralize the selftest by preventing it from verifying or
poisoning unused stolen memory pages?

> +		mutex_unlock(&gt->i915->mm.stolen_lock);
> +		if (unused)
>  			memset_io(s, STACK_MAGIC, PAGE_SIZE);

[Severity: Medium]
This is a pre-existing issue, but is there a time-of-check to time-of-use
(TOCTOU) race condition here?

The lock gt->i915->mm.stolen_lock is released immediately after checking
the page availability, and before memset_io() poisons it.

Could a concurrent thread allocate this page before memset_io() writes
STACK_MAGIC to it, leading to unintended memory corruption of legitimate
stolen memory allocations?

>  
>  		in = (void __force *)s;

[ ... ]

> @@ -143,10 +147,12 @@ __igt_reset_stolen(struct intel_gt *gt,
>  			in = tmp;
>  		x = crc32_le(0, in, PAGE_SIZE);
>  
> -		if (x != crc[page] &&
> -		    !__drm_mm_interval_first(&gt->i915->mm.stolen,
> -					     page << PAGE_SHIFT,
> -					     ((page + 1) << PAGE_SHIFT) - 1)) {
> +		mutex_lock(&gt->i915->mm.stolen_lock);
> +		unused = !__drm_mm_interval_first(&gt->i915->mm.stolen,
> +						  page << PAGE_SHIFT,
> +						  ((page + 1) << PAGE_SHIFT) - 1);
> +		mutex_unlock(&gt->i915->mm.stolen_lock);
> +		if (x != crc[page] && unused) {

[Severity: Medium]
This is a pre-existing issue, but this check for clobbered unused pages
appears to also be neutralized by the always-false condition described
above since unused will always be false.

>  			pr_debug("unused stolen page %pa modified by GPU reset\n",
>  				 &page);
>  			if (count++ == 0)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260821134044.15908-1-sebastian.brzezinka@intel.com?part=1

  reply	other threads:[~2026-08-21 13:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21 13:40 [PATCH] drm/i915/selftests: Fix unlocked mm.stolen in reset selftest Sebastian Brzezinka
2026-08-21 13:48 ` sashiko-bot [this message]
2026-08-21 14:36 ` ✓ i915.CI.BAT: success for " Patchwork
2026-08-21 18:19 ` ✗ i915.CI.Full: failure " Patchwork
2026-08-25 16:29 ` ✓ i915.CI.BAT: success for drm/i915/selftests: Fix unlocked mm.stolen in reset selftest (rev2) Patchwork
2026-08-25 19:36 ` ✗ i915.CI.Full: failure " Patchwork
2026-08-26  8:49 ` [PATCH] drm/i915/selftests: Fix unlocked mm.stolen in reset selftest Krzysztof Karas
2026-08-26  9:11   ` Sebastian Brzezinka
2026-08-26 17:31 ` Andi Shyti
2026-08-27  8:39   ` Sebastian Brzezinka
2026-08-27 23:17     ` Andi Shyti

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=20260821134821.6FCA21F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sebastian.brzezinka@intel.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;
as well as URLs for NNTP newsgroup(s).