Patch "drm/amdgpu: Fix init ordering in amdgpu_vram_mgr_init()" has been added to the 6.18-stable tree

Patch "drm/amdgpu: Fix init ordering in amdgpu_vram_mgr_init()" has been added to the 6.18-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    drm/amdgpu: Fix init ordering in amdgpu_vram_mgr_init()

to the 6.18-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     drm-amdgpu-fix-init-ordering-in-amdgpu_vram_mgr_init.patch
and it can be found in the queue-6.18 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


From e773798e14ac0aea54ca9676083b91f445e5bc59 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= <thomas.hellstrom@linux.intel.com>
Date: Sat, 25 Jul 2026 12:00:31 +0200
Subject: drm/amdgpu: Fix init ordering in amdgpu_vram_mgr_init()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Thomas Hellström <thomas.hellstrom@linux.intel.com>

commit e773798e14ac0aea54ca9676083b91f445e5bc59 upstream.

drmm_cgroup_register_region() is called before INIT_LIST_HEAD() and
gpu_buddy_init() in amdgpu_vram_mgr_init(). If it fails, the function
returns early and bypasses those initializations.

Since adev->mman.initialized is set to true before amdgpu_vram_mgr_init()
is called, a failure triggers amdgpu_ttm_fini(), which calls
amdgpu_vram_mgr_fini(), which then:

 - Calls list_for_each_entry_safe() on reservations_pending and
   reserved_pages, whose list_head::next pointers are zero-initialized
   (NULL). The loop does not recognize them as empty and dereferences NULL.

 - Calls gpu_buddy_fini(), which iterates free_trees[] unconditionally
   via for_each_free_tree(). Since mm->free_trees is NULL
   (never allocated), this dereferences NULL.

Both result in a kernel panic on the module load error path.

Fix by moving drmm_cgroup_register_region() to after the list and buddy
allocator are fully initialized, so the teardown path is safe to run.

Reported-by: Sashiko-bot <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260428073116.15687-1-thomas.hellstrom@linux.intel.com?part=4
Fixes: 2b624a2c1865 ("drm/ttm: Handle cgroup based eviction in TTM")
Cc: Friedrich Vock <friedrich.vock@gmx.de>
Cc: Maarten Lankhorst <dev@lankhorst.se>
Cc: Tejun Heo <tj@kernel.org>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: stable@vger.kernel.org # v6.14+
Assisted-by: GitHub_Copilot:claude-sonnet-4.6
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Reviewed-By: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Link: https://patch.msgid.link/20260725100036.2372-2-thomas.hellstrom@linux.intel.com
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -918,9 +918,6 @@ int amdgpu_vram_mgr_init(struct amdgpu_d
 	struct ttm_resource_manager *man = &mgr->manager;
 	int err;
 
-	man->cg = drmm_cgroup_register_region(adev_to_drm(adev), "vram", adev->gmc.real_vram_size);
-	if (IS_ERR(man->cg))
-		return PTR_ERR(man->cg);
 	ttm_resource_manager_init(man, &adev->mman.bdev,
 				  adev->gmc.real_vram_size);
 
@@ -935,6 +932,10 @@ int amdgpu_vram_mgr_init(struct amdgpu_d
 	if (err)
 		return err;
 
+	man->cg = drmm_cgroup_register_region(adev_to_drm(adev), "vram", adev->gmc.real_vram_size);
+	if (IS_ERR(man->cg))
+		return PTR_ERR(man->cg);
+
 	ttm_set_driver_manager(&adev->mman.bdev, TTM_PL_VRAM, &mgr->manager);
 	ttm_resource_manager_set_used(man, true);
 	return 0;


Patches currently in stable-queue which might be from thomas.hellstrom@linux.intel.com are

queue-6.18/drm-amdgpu-fix-init-ordering-in-amdgpu_vram_mgr_init.patch

Re: Patch "drm/amdgpu: Fix init ordering in amdgpu_vram_mgr_init()" has been added to the 6.18-stable tree

[sashiko-bot]

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

Pre-existing issues:
- [High] If `drm_buddy_init()` fails, it frees its internal structures but leaves dangling pointers and a non-zero `mm->n_roots`. `amdgpu_vram_mgr_fini()` then unconditionally calls `drm_buddy_fini()`, which dereferences these pointers, causing a Use-After-Free or NULL pointer dereference crash.
--

commit 952cbc7ae0fee615a078c5b60b31a61af5185d75
Author: gregkh@linuxfoundation.org <gregkh@linuxfoundation.org>

Patch "drm/amdgpu: Fix init ordering in amdgpu_vram_mgr_init()" has been added to the 6.18-stable tree

This patch fixes an initialization ordering issue in amdgpu_vram_mgr_init().
It moves drmm_cgroup_register_region() to after the list and buddy allocator
are fully initialized. This prevents the module load error path from
dereferencing uninitialized list pointers or NULL pointers.

Link: https://patch.msgid.link/20260725100036.2372-2-thomas.hellstrom@linux.intel.com

> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> index 9d934c07fa6b8..2e457a0388a32 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c

[ ... ]

> @@ -934,6 +931,10 @@ int amdgpu_vram_mgr_init(struct amdgpu_device *adev)
>  	if (err)
>  		return err;

[Severity: High]
This isn't a bug introduced by this patch, but can we still encounter a
kernel panic on the error path if drm_buddy_init() fails?

If drm_buddy_init() fails, it frees mm->roots on its error path but leaves
mm->n_roots > 0:

drivers/gpu/drm/drm_buddy.c:drm_buddy_init() {
    ...
    mm->n_roots = hweight64(size);
    ...
    do {
        ...
        root = drm_block_alloc(mm, NULL, order, offset);
        if (!root)
            goto out_free_roots;
    ...
out_free_roots:
    while (i--)
        drm_block_free(mm, mm->roots[i]);
    kfree(mm->roots);
    ...
}

Because the driver teardown path calls amdgpu_vram_mgr_fini() which
unconditionally calls drm_buddy_fini(), doesn't this result in
dereferencing the freed mm->roots array since mm->n_roots is still > 0?

drivers/gpu/drm/drm_buddy.c:drm_buddy_fini() {
    ...
    for (i = 0; i < mm->n_roots; ++i) {
        order = ilog2(size) - ilog2(mm->chunk_size);
        start = drm_buddy_block_offset(mm->roots[i]);
    ...
}

Could the error path in drm_buddy_init() reset mm->n_roots to 0, or could
amdgpu_vram_mgr_fini() skip calling drm_buddy_fini() if initialization failed?

> +	man->cg = drmm_cgroup_register_region(adev_to_drm(adev), "vram", adev->gmc.real_vram_size);
> +	if (IS_ERR(man->cg))
> +		return PTR_ERR(man->cg);
> +
>  	ttm_set_driver_manager(&adev->mman.bdev, TTM_PL_VRAM, &mgr->manager);
>  	ttm_resource_manager_set_used(man, true);
>  	return 0;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/2026090937-mangle-cinema-f62f@gregkh?part=1