From: sashiko-bot@kernel.org
To: "Umesh Nerlige Ramappa" <umesh.nerlige.ramappa@intel.com>,
intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v3 1/5] drm/xe/oa: Use the drm device address_space for the OA stream fd
Date: Wed, 04 Nov 2026 01:10:52 +0000 [thread overview]
Message-ID: <sashiko-outbox-196348@kernel.org> (raw)
In-Reply-To: <20261104005221.3230003-8-umesh.nerlige.ramappa@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/xe/oa: missing vm_pgoff check in xe_oa_mmap() allows OOB fault
--
commit fbfcd89abe0e799c3080815623130528c7cfb1de
Author: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
drm/xe/oa: Use the drm device address_space for the OA stream fd
This commit points the OA stream file's f_mapping at the DRM device's
anon_inode address_space so that drm_dev_unplug() zaps OA buffer mmaps
alongside GEM mmaps when the device is unplugged.
> diff --git a/drivers/gpu/drm/xe/xe_oa.c b/drivers/gpu/drm/xe/xe_oa.c
> index 838802482adaf..09043bc90de94 100644
> --- a/drivers/gpu/drm/xe/xe_oa.c
> +++ b/drivers/gpu/drm/xe/xe_oa.c
> @@ -1869,6 +1869,7 @@ static int xe_oa_stream_open_ioctl_locked(struct xe_oa *oa,
> {
> struct xe_oa_stream *stream;
> struct drm_syncobj *ufence_syncobj;
> + struct file *file;
> int stream_fd;
> int ret;
>
> @@ -1910,12 +1911,27 @@ static int xe_oa_stream_open_ioctl_locked(struct xe_oa *oa,
> goto err_destroy;
> }
>
> - stream_fd = anon_inode_getfd("[xe_oa]", &xe_oa_fops, stream, 0);
> + stream_fd = get_unused_fd_flags(0);
> if (stream_fd < 0) {
> ret = stream_fd;
> goto err_disable;
> }
>
> + file = anon_inode_getfile("[xe_oa]", &xe_oa_fops, stream, 0);
> + if (IS_ERR(file)) {
> + ret = PTR_ERR(file);
> + put_unused_fd(stream_fd);
> + goto err_disable;
> + }
> +
> + /*
> + * Don't use the address_space of the anon inode singleton, which is shared with
> + * unrelated anon files. Use the drm device's address_space instead, same as drm fds,
> + * so that drm_dev_unplug() also zaps the OA buffer mmaps.
> + */
> + file->f_mapping = oa->xe->drm.anon_inode->i_mapping;
> + fd_install(stream_fd, file);
[Severity: High]
Does sharing oa->xe->drm.anon_inode->i_mapping require xe_oa_mmap() to
reject a non-zero vma->vm_pgoff?
The commit message notes that GEM mmaps live at fake offsets starting at
DRM_FILE_PAGE_OFFSET_START while userspace maps the OA buffer at offset 0.
However, in drivers/gpu/drm/xe/xe_oa.c, xe_oa_mmap() only checks the VMA
size and does not verify that vma->vm_pgoff is 0:
drivers/gpu/drm/xe/xe_oa.c:xe_oa_mmap() {
...
/* Can mmap the entire OA buffer or nothing (no partial OA buffer mmaps) */
if (vma->vm_end - vma->vm_start != xe_bo_size(bo)) {
drm_dbg(&stream->oa->xe->drm, "Wrong mmap size, must be OA buffer size\n");
return -EINVAL;
}
return drm_gem_mmap_obj(&bo->ttm.base, xe_bo_size(bo), vma);
}
Because stream_fd is backed by anon_inode_inode (which is not S_ISREG),
do_mmap() allows arbitrary page-aligned offsets, and neither xe_oa_mmap()
nor the drm_gem_mmap_obj() -> xe_gem_object_mmap() -> drm_gem_ttm_mmap() ->
ttm_bo_mmap_obj() call chain checks vma->vm_pgoff.
If userspace calls mmap() on stream_fd with a non-zero offset in the
DRM_FILE_PAGE_OFFSET_START range, the OA VMA is inserted into
oa->xe->drm.anon_inode->i_mapping->i_mmap at [vma->vm_pgoff,
vma->vm_pgoff + vma_pages(vma) - 1], colliding with GEM BO vma_node ranges
so that drm_vma_node_unmap() on a GEM BO at that range will unexpectedly
zap the OA VMA.
In addition, stream->oa_buffer.bo is allocated in xe_oa_alloc_oa_buffer()
as ttm_bo_type_kernel, so drm_vma_node_start(&bo->ttm.base.vma_node) is 0.
When a page fault occurs via xe_bo_cpu_fault() -> __xe_bo_cpu_fault() ->
ttm_bo_vm_fault_reserved() in drivers/gpu/drm/ttm/ttm_bo_vm.c:
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;
...
}
If 0 < vma->vm_pgoff < PFN_UP(bo->base.size) and userspace faults at an
address where page_offset < PFN_UP(bo->base.size) (for example,
PFN_UP(bo->base.size) - 1), the initial bounds check passes, and the
prefault loop increments page_offset up to page_last - 1 (which is
vma->vm_pgoff + PFN_UP(bo->base.size) - 1), reading past the end of
ttm->pages[] or the BO's VRAM resource and mapping out-of-bounds physical
pages into userspace?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261104005221.3230003-7-umesh.nerlige.ramappa@intel.com?part=1
next prev parent reply other threads:[~2026-11-04 1:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 0:52 [PATCH v3 0/5] Cleanup OA stream on PCI unbind/remove Umesh Nerlige Ramappa
2026-11-04 0:52 ` [PATCH v3 1/5] drm/xe/oa: Use the drm device address_space for the OA stream fd Umesh Nerlige Ramappa
2026-11-04 1:10 ` sashiko-bot [this message]
2026-11-04 0:52 ` [PATCH v3 2/5] drm/xe/oa: Split OA stream destroy into HW teardown and resource release Umesh Nerlige Ramappa
2026-11-04 0:52 ` [PATCH v3 3/5] drm/xe/oa: Take the runtime PM reference in xe_oa_destroy_locked() Umesh Nerlige Ramappa
2026-11-04 0:52 ` [PATCH v3 4/5] drm/xe: Reject vm_ops->access on BO mappings of an unplugged device Umesh Nerlige Ramappa
2026-11-04 0:52 ` [PATCH v3 5/5] drm/xe/oa: Quiesce OA streams on driver unbind and PCI reset Umesh Nerlige Ramappa
2026-11-04 1:35 ` sashiko-bot
2026-11-04 1:13 ` ✓ CI.KUnit: success for Cleanup OA stream on PCI unbind/remove (rev3) Patchwork
2026-11-04 1:57 ` ✓ Xe.CI.BAT: " Patchwork
2026-11-04 16:50 ` ✓ 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=sashiko-outbox-196348@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=umesh.nerlige.ramappa@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 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.