FAILED: patch "[PATCH] nouveau/gem: reserve the bo in the info ioctl around the vma" failed to apply to 5.15-stable tree
Subsystems (4)
[email protected]
maintainerThe patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y
git checkout FETCH_HEAD
git cherry-pick -x 5e17160d41d92823f3379c1982e1369680c5ce4d
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2026090305-skeleton-brush-8637@gregkh' --subject-prefix 'PATCH 5.15.y' 'HEAD^..'
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 5e17160d41d92823f3379c1982e1369680c5ce4d Mon Sep 17 00:00:00 2001
From: Dave Airlie <[email protected]>
Date: Fri, 12 Jun 2026 12:06:58 +1000
Subject: [PATCH] nouveau/gem: reserve the bo in the info ioctl around the vma
lookup
In the non-uvmm path, there could be a race between the info lookup finding the vma, and the gem close path closing the vma leading to a use-after-free.
Spotted with the help of Opus 4.6.
drivers/gpu/drm/nouveau/nouveau_gem.c +10 -1
@@ -313,11 +313,20 @@ nouveau_gem_info(struct drm_file *file_priv, struct drm_gem_object *gem, rep->offset = nvbo->offset;if (vmm->vmm.object.oclass >=NVIF_CLASS_VMM_NV50 && !nouveau_cli_uvmm (cli)) { +int ret; + + ret =ttm_bo_reserve (&nvbo->bo, false, false,NULL ); +if (ret) +return ret; + vma =nouveau_vma_find (nvbo, vmm); -if (!vma) +if (!vma) { +ttm_bo_unreserve (&nvbo->bo);return -EINVAL ; + } rep->offset = vma->addr; +ttm_bo_unreserve (&nvbo->bo); }else rep->offset =0 ;
Sasha Levin
maintainerPATCH 1/1 nouveau/gem: reserve the bo in the info ioctl around the vma lookup
From: Dave Airlie <[email protected]>
[ Upstream commit 5e17160d41d92823f3379c1982e1369680c5ce4d ]
In the non-uvmm path, there could be a race between the info lookup finding the vma, and the gem close path closing the vma leading to a use-after-free.
Spotted with the help of Opus 4.6.
--- drivers/gpu/drm/nouveau/nouveau_gem.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
drivers/gpu/drm/nouveau/nouveau_gem.c +10 -1
@@ -277,11 +277,20 @@ nouveau_gem_info(struct drm_file *file_priv, struct drm_gem_object *gem, rep->domain =NOUVEAU_GEM_DOMAIN_VRAM ; rep->offset = nvbo->offset;if (vmm->vmm.object.oclass >=NVIF_CLASS_VMM_NV50 ) { +int ret; + + ret =ttm_bo_reserve (&nvbo->bo, false, false,NULL ); +if (ret) +return ret; + vma =nouveau_vma_find (nvbo, vmm); -if (!vma) +if (!vma) { +ttm_bo_unreserve (&nvbo->bo);return -EINVAL ; + } rep->offset = vma->addr; +ttm_bo_unreserve (&nvbo->bo); } rep->size = nvbo->bo.base.size;
Signature · 1 line
2.53.0