From: sashiko-bot@kernel.org
To: "Matthew Brost" <matthew.brost@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 4/6] drm/pagemap: dma-unmap pages before handling migration errors
Date: Wed, 05 Aug 2026 23:22:14 +0000 [thread overview]
Message-ID: <20260805232215.439271F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260805231041.3791771-5-matthew.brost@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Valid DMA address 0 is leaked because `drm_pagemap_migrate_unmap_pages` skips unmapping when `pagemap_addr[i].addr == 0`, leading to a stale IOMMU mapping and potential use-after-free.
--
--- Patch [4]: [PATCH v3 4/6] drm/pagemap: dma-unmap pages before handling migration errors ---
commit 449a54e82e1a7fd00fc19c70ae34414088711db1
Author: Matthew Brost <matthew.brost@intel.com>
drm/pagemap: dma-unmap pages before handling migration errors
This commit reorders the cleanup sequence during migration errors. It ensures
that DMA unmapping occurs before the pages array is cleared, preventing missing
unmaps due to invalid page information.
> diff --git a/drivers/gpu/drm/drm_pagemap.c b/drivers/gpu/drm/drm_pagemap.c
> index 892b325fa99b8..aef1fcea663d5 100644
> --- a/drivers/gpu/drm/drm_pagemap.c
> +++ b/drivers/gpu/drm/drm_pagemap.c
> @@ -1175,12 +1175,12 @@ int drm_pagemap_evict_to_ram(struct drm_pagemap_devmem *devmem_allocation)
> goto err_finalize;
>
> err_finalize:
> + drm_pagemap_migrate_unmap_pages(devmem_allocation->dev, pagemap_addr, dst, npages,
> + DMA_FROM_DEVICE, &state);
[Severity: Critical]
This is a pre-existing issue, but does the check inside
drm_pagemap_migrate_unmap_pages() accidentally leak valid DMA address 0?
drivers/gpu/drm/drm_pagemap.c:drm_pagemap_migrate_unmap_pages() {
...
if (!page || !pagemap_addr[i].addr || dma_mapping_error(dev, pagemap_addr[i].addr))
goto next;
...
}
Since 0 is a valid DMA address on many platforms, skipping the unmap when
pagemap_addr[i].addr == 0 might leave a stale IOMMU mapping.
When the page is subsequently freed, could a malicious userspace instruct the
GPU to access this DMA address and cause memory corruption or an IOMMU
use-after-free?
> if (err)
> drm_pagemap_migration_unlock_put_pages(npages, dst);
> migrate_device_pages(src, dst, npages);
> migrate_device_finalize(src, dst, npages);
> - drm_pagemap_migrate_unmap_pages(devmem_allocation->dev, pagemap_addr, dst, npages,
> - DMA_FROM_DEVICE, &state);
>
> err_free:
> kvfree(buf);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260805231041.3791771-1-matthew.brost@intel.com?part=4
next prev parent reply other threads:[~2026-08-05 23:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 23:10 [PATCH v3 0/6] Fix device page migration in low memory fallback Matthew Brost
2026-08-05 23:10 ` [PATCH v3 1/6] mm/migrate_device: Clear stale mapping after freeing swapcache Matthew Brost
2026-08-05 23:22 ` sashiko-bot
2026-08-05 23:10 ` [PATCH v3 2/6] mm/migrate_device: Do not write past the end of the src_pfns array Matthew Brost
2026-08-05 23:25 ` sashiko-bot
2026-08-05 23:29 ` Balbir Singh
2026-08-05 23:10 ` [PATCH v3 3/6] mm/migrate_device: Fix THP splitting of a CPU faulted device private folio Matthew Brost
2026-08-06 8:10 ` Balbir Singh
2026-08-10 2:26 ` Huang, Ying
2026-08-10 19:43 ` Matthew Brost
2026-08-12 8:20 ` Huang, Ying
2026-08-05 23:10 ` [PATCH v3 4/6] drm/pagemap: dma-unmap pages before handling migration errors Matthew Brost
2026-08-05 23:22 ` sashiko-bot [this message]
2026-08-05 23:10 ` [PATCH v3 5/6] drm/pagemap: Fix folio allocation fallback and use-after-put Matthew Brost
2026-08-05 23:10 ` [PATCH v3 6/6] drm/pagemap: Add fault injection for higher-order RAM folio allocation Matthew Brost
2026-08-05 23:24 ` sashiko-bot
2026-08-05 23:17 ` ✗ CI.checkpatch: warning for Fix device page migration in low memory fallback (rev3) Patchwork
2026-08-05 23:18 ` ✓ CI.KUnit: success " Patchwork
2026-08-06 0:02 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-06 9:15 ` ✓ Xe.CI.FULL: " Patchwork
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=20260805232215.439271F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=sashiko-reviews@lists.linux.dev \
/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.