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 <[email protected]> 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/[email protected]?part=1
