• File: sys/dev/drm/amd/amdgpu/amdgpu_fb.c
• Lines: 228, 237–252 (error paths), 308–316 (broken cleanup)
• Severity: Medium
• CVSS 3.1: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U:C:N/I:N/A:L
• CWE: CWE-401 Missing Release of Memory after Effective Lifetime
• Confidence: certain
• Status: new
• Related: DF-1969 (radeon_fb.c identical-class bug)

Summary

When drm_fb_helper_alloc_fbi() (line 237) or amdgpu_display_framebuffer_init() (line 248) fails after amdgpufb_create_pinned_object() (line 228) succeeds, the out: error label has broken cleanup: the if (abo) { } block is empty (lines 309-311) and if (fb && ret) at line 312 is false because fb is still NULL at those error points.

The GEM object's reference count is never decremented, permanently leaking the pinned VRAM buffer object.

Root cause

In amdgpufb_create(), after amdgpufb_create_pinned_object(rfbdev, &mode_cmd, &gobj) succeeds at line 228, gobj holds a reference to a pinned+kmap'd VRAM buffer object.

Two error paths follow:

• Path A: drm_fb_helper_alloc_fbi(helper) at line 237 returns IS_ERR(info) → goto out (line 240). At this point fb is still NULL (set only at line 255, after framebuffer_init succeeds).
• Path B: amdgpu_display_framebuffer_init() at line 248 fails → goto out (line 252). fb is still NULL.

At the out: label (line 308): - if (abo) { } (line 309) is an EMPTY BLOCK — clearly someone intended cleanup here but left it incomplete. - if (fb && ret) (line 312) is FALSE because fb == NULL on both paths.

So gobj is never released. amdgpufb_destroy_pinned_object() (line 115-127), which does amdgpu_bo_kunmap + amdgpu_bo_unpin + drm_gem_object_put_unlocked, is never called.

The GEM object and its backing VRAM allocation (size = pitches[0] * ALIGN(height, 8), page-aligned, pinned in VRAM) are leaked for the lifetime of the kernel.

Later, amdgpu_fbdev_destroy() (line 321-336) checks if (rfb->base.obj[0]) (line 327) before cleanup. On Path B, amdgpu_display_framebuffer_init sets obj[0]=NULL on failure (amdgpu_display.c:516), so the destroy function skips cleanup entirely. On Path A, obj[0] was never set (still zero from kzalloc). In both cases, the leak is permanent.

Additionally, amdgpu_fbdev_init() at line 383-384 ignores the return value of drm_fb_helper_initial_config and always returns 0, so the driver proceeds as if fbdev init succeeded.

Threat model

Attacker position: local attacker with DRM device access or the ability to trigger display hotplug/modeset events.

Trigger: repeat fbdev re-probe failures to leak several MB of pinned VRAM per attempt. Over time this exhausts VRAM, causing subsequent modeset/scanout allocations to fail → local DoS.

On amdgpu, the framebuffer surface size can be large (e.g., 16384*4 * ALIGN(8640,8) ≈ 572 MB for a 16K display). Even a single leak of this size is significant; repeated leaks via hotplug cycles are devastating.

The attack requires the fb_probe path to fail (e.g., low VRAM, or GART bind failure from amdgpu_ttm_alloc_gart at line 185), which an attacker can influence by consuming VRAM via other DRM allocations.

Proof of concept

1. Open the amdgpu DRM device (/dev/drmX).
2. Allocate large VRAM GEM objects via DRM_IOCTL_AMDKGPU_GEM_CREATE or DRM_IOCTL_MODE_CREATE_DUMB until VRAM is nearly exhausted.
3. Trigger a fbdev re-probe — on DragonFly this happens via connector hotplug (unplug/replug display) or by triggering drm_fb_helper_hotplug_event.
4. amdgpufb_create_pinned_object succeeds (enough VRAM for one object) but amdgpu_ttm_alloc_gart (line 185) fails because GART space is exhausted, or drm_fb_helper_alloc_fbi fails under memory pressure.
5. The GEM object is leaked.
6. Repeat until VRAM is permanently consumed.

Verification: check systat -vmstat or amdgpu VRAM usage sysfs before/after — the leaked objects never appear as freeable.

Success criterion: fbdev/modeset failures after repeated cycling, or OOM from VRAM exhaustion.

Recommended fix

Replace the broken out: error path with proper cleanup. The GEM object must be released on all error paths, and the latent kfree(fb) must be removed (see DF-1983).

--- a/sys/dev/drm/amd/amdgpu/amdgpu_fb.c
+++ b/sys/dev/drm/amd/amdgpu/amdgpu_fb.c
@@ -305,16 +305,14 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
    vga_switcheroo_client_fb_set(adev->ddev->pdev, info);
    return 0;

 out:
-   if (abo) {
-
-   }
-   if (fb && ret) {
-       drm_gem_object_put_unlocked(gobj);
-       drm_framebuffer_unregister_private(fb);
-       drm_framebuffer_cleanup(fb);
-       kfree(fb);
-   }
+   /*
+    * Release the pinned GEM object on any error path.  fb is embedded
+    * in the kzalloc'd rfbdev (never separately allocated), so never
+    * kfree() it -- see amdgpu_mode.h:316-321.
+    */
+   if (gobj)
+       amdgpufb_destroy_pinned_object(gobj);
    return ret;
 }

References

• sys/dev/drm/amd/amdgpu/amdgpu_fb.c:228,237-252 — error-prone init sequence
• sys/dev/drm/amd/amdgpu/amdgpu_fb.c:308-316 — broken error cleanup (empty if(abo){} block)
• sys/dev/drm/amd/amdgpu/amdgpu_fb.c:115-127 — amdgpufb_destroy_pinned_object (the proper cleanup)
• sys/dev/drm/amd/amdgpu/amdgpu_fb.c:383-384 — amdgpu_fbdev_init ignores return value
• sys/dev/drm/amd/amdgpu/amdgpu_display.c:516 — obj[0]=NULL on init failure