From: "Christian König" <christian.koenig@amd.com>
To: Baul Lee <baul.lee@xbow.com>,
ray.huang@amd.com, maarten.lankhorst@linux.intel.com,
mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com,
simona@ffwll.ch
Cc: matthew.auld@intel.com, matthew.brost@intel.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
federico.kirschbaum@xbow.com, stable@vger.kernel.org
Subject: Re: [PATCH] drm/ttm: clamp the prefault window to the buffer object
Date: Thu, 6 Aug 2026 13:38:57 +0200 [thread overview]
Message-ID: <92b02f98-8b9e-4970-a1f7-f3b2c0fcd2d4@amd.com> (raw)
In-Reply-To: <20260806034356.43681-1-baul.lee@xbow.com>
On 8/6/26 05:43, Baul Lee wrote:
> ttm_bo_vm_fault_reserved() derives two page indices from the caller's
> mmap(2) arguments and bounds only one of them:
>
> page_offset = ((address - vma->vm_start) >> PAGE_SHIFT) +
> vma->vm_pgoff - drm_vma_node_start(&bo->base.vma_node);
> page_last = vma_pages(vma) + vma->vm_pgoff -
> drm_vma_node_start(&bo->base.vma_node);
>
> if (unlikely(page_offset >= PFN_UP(bo->base.size)))
> return VM_FAULT_SIGBUS;
>
> bo->base.size appears once in the function, bounding page_offset on
> entry. page_last comes straight from vma_pages(vma) and is the loop
> terminator:
>
> if (unlikely(++page_offset >= page_last))
> break;
>
> so the object size never bounds it. For an object of N pages, a fault
> on the last in-object page passes the entry test with page_offset
> N - 1, and the prefault loop then walks N..N+14, reading
> ttm->pages[page_offset] or
> ttm_bo_io_mem_pfn(bo, page_offset) and installing each frame with
> vmf_insert_pfn_prot().
>
> page_last exceeds the object whenever the VMA is longer than it.
> drm_gem_mmap_obj() rejects that on the DRM node, but the fbdev path
> reaches the object function through drm_gem_prime_mmap(), which does
> not. It is also exceeded by a mapping no longer than the object taken
> at a nonzero file offset, so the handler needs its own bound.
>
> With a 128-page object mapped 192 pages long,
And exactly that sentence explains why this whole patch is superfluous.
A 128 page object absolutely *can't* be mapped into 192 pages VMA!
If we would allow that the driver side could crash extremely badly long before we even get here.
Do you have any reproducer which exercises this?
Regards,
Christian.
> one read fault at index
> N - 1 leaves the fifteen frames after the object readable through the
> mapping; on a fresh mapping, reading index N without first faulting
> N - 1 is SIGBUS. For a system-memory placement the page array is
> over-read as well:
>
> BUG: KASAN: slab-out-of-bounds in ttm_bo_vm_fault_reserved+0x248/0x57c
> Read of size 8 at addr ffff0000078aac00 by task e1/219
> __asan_load8+0x84/0xb0
> ttm_bo_vm_fault_reserved+0x248/0x57c
> ttm_bo_vm_fault+0xe4/0x140
> __do_fault+0x6c/0x2f0
>
> Clamp page_last to the object.
>
> Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
>
> Fixes: ba4e7d973dd0 ("drm: Add the TTM GPU memory manager subsystem.")
> Cc: stable@vger.kernel.org
> Signed-off-by: Baul Lee <baul.lee@xbow.com>
> ---
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index a80510489c45..14ebf6ee3c47 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -212,6 +212,7 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
> vma->vm_pgoff - drm_vma_node_start(&bo->base.vma_node);
> page_last = vma_pages(vma) + vma->vm_pgoff -
> drm_vma_node_start(&bo->base.vma_node);
> + page_last = min_t(unsigned long, page_last, PFN_UP(bo->base.size));
>
> if (unlikely(page_offset >= PFN_UP(bo->base.size)))
> return VM_FAULT_SIGBUS;
> --
> 2.50.1 (Apple Git-155)
prev parent reply other threads:[~2026-08-06 11:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 3:43 Baul Lee
2026-08-06 4:04 ` Matthew Brost
2026-08-06 11:38 ` Christian König [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=92b02f98-8b9e-4970-a1f7-f3b2c0fcd2d4@amd.com \
--to=christian.koenig@amd.com \
--cc=airlied@gmail.com \
--cc=baul.lee@xbow.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=federico.kirschbaum@xbow.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=ray.huang@amd.com \
--cc=simona@ffwll.ch \
--cc=stable@vger.kernel.org \
--cc=tzimmermann@suse.de \
/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
all inboxes | Powered by JetHome®