Summary

On the count > 1 path of amdgpu_pasid_free_delayed, the per-fence references acquired from reservation_object_get_fences_rcu are leaked when dma_fence_array_create fails: the code kfrees the pointer array without first dropping each fence reference. Each occurrence permanently leaks count fence objects (and the buffers they keep alive), reachable from any local user closing a DRM file descriptor whose page-directory reservation object carries two or more shared fences.

Root cause

amdgpu_pasid_free_delayed (amdgpu_ids.c:111-166) calls reservation_object_get_fences_rcu at line 119 which returns fences with a reference taken on each entry (linux_reservation.c:382-386 calls dma_fence_get_rcu per entry).

When count > 1, the code passes fences to dma_fence_array_create at amdgpu_ids.c:135-136; that function (linux_fence-array.c:167-193) documents "dma_fence_put() is used on each fence on release" — i.e. the array steals the caller's references. If dma_fence_array_create returns NULL (kzalloc failure), the correct cleanup is to dma_fence_put each entry before kfree-ing the array — exactly what the sibling amdgpu_prime.c:233-236 does and what amdgpu_vmid_grab_idle does at amdgpu_ids.c:241-246.

amdgpu_ids.c:137-140 instead does only:

kfree(fences);
goto fallback;

permanently leaking one reference per fence in the array.

Threat model & preconditions

• Attacker position: local unprivileged user with access to the AMD GPU render node (/dev/dri/renderD*).
• Privileges gained or impact: slow local denial of service via kernel memory exhaustion. No privilege escalation, no info leak, no memory corruption. Impact is purely resource exhaustion, and only manifests when the system is already in OOM.
• Required config or capabilities: device amdgpu; render node access.
• Reachability: open the device, submit work that shares buffer objects so the page-directory reservation object accumulates >= 2 shared fences, then close the file descriptor under memory pressure so dma_fence_array_create's internal kzalloc fails.

Proof of concept

/* Open render node, submit shared-BO CS, close under OOM pressure */
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <xf86drm.h>
#include <amdgpu.h>

int main(void) {
    for (int iter = 0; iter < 100000; iter++) {
        int fd = open("/dev/dri/renderD128", O_RDWR);
        if (fd < 0) break;
        amdgpu_device_handle dev;
        long major, minor;
        if (amdgpu_device_initialize(fd, &major, &minor, &dev)) {
            close(fd); continue;
        }
        /* Submit CS with shared BOs to accumulate >=2 shared fences */
        /* ...submission omitted; see VERDICT.md for full source... */
        amdgpu_device_deinitialize(dev);
        close(fd);   /* triggers amdgpu_pasid_free_delayed -> leak */
    }
    return 0;
}

Expected output

Monitor vmstat -w 1 / top — kernel malloc'd memory climbs monotonically across iterations even though all user processes exit; free memory never returns to baseline.

Impact

Low-severity resource leak (slow local DoS via memory exhaustion). Only manifests under OOM conditions when dma_fence_array_create's kzalloc fails.

Recommended fix

Mirror the cleanup pattern used in amdgpu_vmid_grab_idle and amdgpu_prime.c. Drop each fence reference before kfree-ing the array.

--- a/sys/dev/drm/amd/amdgpu/amdgpu_ids.c
+++ b/sys/dev/drm/amd/amdgpu/amdgpu_ids.c
@@ -133,8 +133,14 @@ void amdgpu_pasid_free_delayed(struct reservation_object *resv,
        array = dma_fence_array_create(count, fences, context,
                           1, false);
        if (!array) {
+           unsigned i;
+
+           /* dma_fence_array_create failed: it did not consume the
+            * fence references we acquired from
+            * reservation_object_get_fences_rcu. Drop them before
+            * freeing the pointer array. */
+           for (i = 0; i < count; ++i)
+               dma_fence_put(fences[i]);
            kfree(fences);
            goto fallback;
        }

References

• Correct sibling pattern: amdgpu_vmid_grab_idle amdgpu_ids.c:241-246; amdgpu_prime.c:233-236.
• dma_fence_array_create steals references: linux_fence-array.c:167-193.

Timeline

• 2026-07-20 Discovered during automated audit.
• 2026-07-20 Reported to DragonFlyBSD security contact (pending).