[PATCH] drm/xe: Fix reference count leak in xe_pci_barrier_mmap()

[PATCH] drm/xe: Fix reference count leak in xe_pci_barrier_mmap()

[yaolu]

From: Lu Yao <yaolu@kylinos.cn>

xe_pci_barrier_mmap() function called drm_dev_get() when setting up
the VMA, but never released. The vm_ops .open/.close callbacks
already handle reference counting correctly.

Fixes: 75d37750a753 ("drm/xe/mmap: Add mmap support for PCI memory barrier")
Signed-off-by: Lu Yao <yaolu@kylinos.cn>
---
 drivers/gpu/drm/xe/xe_device.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index abe25aedeead..3b5a2fad697f 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -340,7 +340,6 @@ static int xe_pci_barrier_mmap(struct file *filp,
 	vm_flags_set(vma, VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP | VM_IO);
 	vma->vm_ops = &vm_ops_barrier;
 	vma->vm_private_data = dev;
-	drm_dev_get(vma->vm_private_data);
 
 	return 0;
 }
-- 
2.25.1

Re: [PATCH] drm/xe: Fix reference count leak in xe_pci_barrier_mmap()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing `drm_dev_get()` from `xe_pci_barrier_mmap()` causes a device reference count underflow, leading to a potential use-after-free of the `xe_device`.
--

--- Patch [1]: [PATCH] drm/xe: Fix reference count leak in xe_pci_barrier_mmap() ---
commit fb6604d312d887a8133909c7e0434e96c90e6a7d
Author: Lu Yao <yaolu@kylinos.cn>

drm/xe: Fix reference count leak in xe_pci_barrier_mmap()

This commit removes a drm_dev_get() call in xe_pci_barrier_mmap(), with the
stated assumption that the vm_ops .open and .close callbacks already handle
the reference counting.

> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
> @@ -341,7 +341,6 @@ static int xe_pci_barrier_mmap(struct file *filp,
>  	vm_flags_set(vma, VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP | VM_IO);
>  	vma->vm_ops = &vm_ops_barrier;
>  	vma->vm_private_data = dev;
> -	drm_dev_get(vma->vm_private_data);

[Severity: High]
Will this removal lead to a device reference count underflow when the VMA
is eventually closed?

The memory management subsystem does not call a VMA's .open callback upon
initial creation via mmap(), it is only invoked during VMA duplication
like fork() or mremap(). Because the explicit drm_dev_get() is removed
in xe_pci_barrier_mmap(), the initial VMA is created without incrementing
the device reference count.

When the VMA is unmapped, barrier_close() unconditionally drops a reference:

static void barrier_close(struct vm_area_struct *vma)
{
        drm_dev_put(vma->vm_private_data);
}

Does this unmatched put cause a reference count underflow and potential
use-after-free of the drm_device?

>  
>  	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709123252.302944-1-yaolu@kylinos.cn?part=1