From: Matthew Brost <matthew.brost@intel.com>
To: Baul Lee <baul.lee@xbow.com>
Cc: <christian.koenig@amd.com>, <ray.huang@amd.com>,
<maarten.lankhorst@linux.intel.com>, <mripard@kernel.org>,
<tzimmermann@suse.de>, <airlied@gmail.com>, <simona@ffwll.ch>,
<matthew.auld@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: Wed, 5 Aug 2026 21:04:51 -0700 [thread overview]
Message-ID: <anQH45cRIFOA/X3w@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <20260806034356.43681-1-baul.lee@xbow.com>
On Thu, Aug 06, 2026 at 12:43:56PM +0900, 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, 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>
You are going to want an Assisted-by tag here as XBOW is an AI tool?
>
> Fixes: ba4e7d973dd0 ("drm: Add the TTM GPU memory manager subsystem.")
This won't apply to ba4e7d973dd0. More below.
> 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));
This looks correct but maybe to make backporting easier all the way to
ba4e7d973dd0, we do this instead...
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index a80510489c45..3529371a37d5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -274,7 +274,8 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
}
address += PAGE_SIZE;
- if (unlikely(++page_offset >= page_last))
+ if (unlikely(++page_offset >= page_last ||
+ page_offset >= PFN_UP(bo->base.size)))
break;
}
return ret;
The above code git blame show this line was last modified in
ba4e7d973dd0.
Then in non-fixes patch, do it like you have it here.
Matt
>
> if (unlikely(page_offset >= PFN_UP(bo->base.size)))
> return VM_FAULT_SIGBUS;
> --
> 2.50.1 (Apple Git-155)
next prev parent reply other threads:[~2026-08-06 4:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 3:43 [PATCH] drm/ttm: clamp the prefault window to the buffer object Baul Lee
2026-08-06 3:54 ` sashiko-bot
2026-08-06 4:04 ` Matthew Brost [this message]
2026-08-06 11:38 ` Christian König
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=anQH45cRIFOA/X3w@gsse-cloud1.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=airlied@gmail.com \
--cc=baul.lee@xbow.com \
--cc=christian.koenig@amd.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=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 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.