Re: [PATCH v2 1/5] drm/nouveau: Fix cleanup bug in nouveau_drm_device_new()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Use-After-Free on DRM driver private data (`struct nouveau_drm`) when userspace retains file descriptors or GEM objects after the physical device is unbound.
--

--- Patch [1]: [PATCH v2 1/5] drm/nouveau: Fix cleanup bug in nouveau_drm_device_new() ---
commit 915c6f6927c7e80b9c5ab3b1a2ff665d1e795afc
Author: Lyude Paul <lyude@redhat.com>

drm/nouveau: Fix cleanup bug in nouveau_drm_device_new()

This commit converts the allocation of struct nouveau_drm to use devres
to simplify the cleanup path.

> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 4d1ad718e09b7..9570850656126 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
[ ... ]
> @@ -740,17 +739,15 @@ nouveau_drm_device_new(const struct drm_driver *drm_driver, struct device *paren
>  	struct nouveau_drm *drm;
>  	int ret;
>  
> -	drm = kzalloc_obj(*drm);
> +	drm = devm_kzalloc(parent, sizeof(*drm), GFP_KERNEL);

[Severity: High]
This isn't a bug introduced by this patch, but doesn't tying the allocation
of struct nouveau_drm to the physical device's devres lifecycle preserve a
use-after-free condition?

If a user opens the DRM device, allocates a GEM object, and holds onto it
across a device unbind (such as a module unload or hot-unplug), the device
removal will trigger devres cleanup and free this devm_kzalloc'd memory.

Later, when the user drops the last reference to the GEM object, the DRM core
cleans it up and eventually calls nouveau_gem_object_del(). This function
derives the nouveau_drm pointer from the GEM object's embedded TTM buffer
object and dereferences it, accessing the freed memory. TTM core functions
will also access the dangling ttm_device embedded in the freed nouveau_drm
struct.

Would it be safer to use drmm_kzalloc() here so the driver-private data lives
exactly as long as the drm_device refcount?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730195523.1467423-1-lyude@redhat.com?part=1