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

[sashiko-bot@kernel.org]

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