From: sashiko-bot@kernel.org
To: kaii-k <harshicon28@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/ttm: check for NULL resource in ttm_bo_vm_fault_reserved()
Date: Tue, 10 Nov 2026 09:22:56 +0000 [thread overview]
Message-ID: <sashiko-outbox-206721@kernel.org> (raw)
In-Reply-To: <20261109202330.1816799-3-harshicon28@gmail.com>
Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Critical] drm/xe/oa: missing vm_pgoff check in xe_oa_mmap() [1]
--
commit e95d22b6c456f4e471c0ed18ffb86dc352011af3
Author: Harsh Parmar <kaii02ctf@gmail.com>
drm/ttm: check for NULL resource in ttm_bo_vm_fault_reserved()
This commit adds a NULL check on bo->resource in ttm_bo_vm_fault_reserved()
and returns VM_FAULT_SIGBUS when a buffer object has no backing store.
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 872bf444b1f0f..69dd6bdd54022 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -205,6 +205,9 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
> if (unlikely(ret != 0))
> return ret;
>
> + if (unlikely(!bo->resource))
> + return VM_FAULT_SIGBUS;
> +
> err = ttm_mem_io_reserve(bo->bdev, bo->resource);
> if (unlikely(err != 0))
> return VM_FAULT_SIGBUS;
[Severity: Critical]
This problem wasn't introduced by this patch, but can the prefault loop in
ttm_bo_vm_fault_reserved() read past the end of ttm->pages[] [1] when a
VMA has a non-zero vm_pgoff?
drivers/gpu/drm/ttm/ttm_bo_vm.c:ttm_bo_vm_fault_reserved() {
...
page_offset = linear_page_index(vma, address) -
drm_vma_node_start(&bo->base.vma_node);
page_last = vma_end_pgoff(vma) -
drm_vma_node_start(&bo->base.vma_node);
if (unlikely(page_offset >= PFN_UP(bo->base.size)))
return VM_FAULT_SIGBUS;
...
for (i = 0; i < num_prefault; ++i) {
if (bo->resource->bus.is_iomem) {
pfn = ttm_bo_io_mem_pfn(bo, page_offset);
} else {
page = ttm->pages[page_offset];
...
pfn = page_to_pfn(page);
}
...
ret = vmf_insert_pfn_prot(vma, address, pfn, prot);
...
address += PAGE_SIZE;
if (unlikely(++page_offset >= page_last))
break;
}
}
For example, xe_oa_mmap() checks that the VMA size equals xe_bo_size(bo)
before calling drm_gem_mmap_obj(), but neither checks nor zeroes
vma->vm_pgoff. Because stream->oa_buffer.bo is a ttm_bo_type_kernel object,
drm_vma_node_start(&bo->base.vma_node) is 0 and page_last becomes
vma->vm_pgoff + PFN_UP(bo->base.size). A fault near the end of the buffer
passes the initial PFN_UP(bo->base.size) check, and the prefault loop then
steps page_offset past PFN_UP(bo->base.size) toward page_last, dereferencing
out-of-bounds ttm->pages[] entries or mapping out-of-bounds PFNs into
userspace.
[1] https://sashiko.dev/#/bug/linux-d5cc9df6-b93b-44e4-8837-59f1909411f7
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261109202330.1816799-1-harshicon28@gmail.com?part=3
next prev parent reply other threads:[~2026-11-10 9:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 20:23 [PATCH 1/3] drm/ttm: check for NULL resource in ttm_bo_kmap() kaii-k
2026-11-09 20:23 ` [PATCH 2/3] drm/ttm: check for NULL resource in ttm_bo_vmap() kaii-k
2026-11-09 20:23 ` [PATCH 3/3] drm/ttm: check for NULL resource in ttm_bo_vm_fault_reserved() kaii-k
2026-11-10 9:22 ` sashiko-bot [this message]
2026-11-10 8:58 ` [PATCH 1/3] drm/ttm: check for NULL resource in ttm_bo_kmap() sashiko-bot
2026-11-10 9:24 ` 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=sashiko-outbox-206721@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=harshicon28@gmail.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.