Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox