Summary

radeon_uvd_cs_msg calls radeon_bo_kmap(bo, &ptr) at line 489 to map the message BO, but two error returns — the handle==0 path at lines 500-503 and the illegal-msg-type default case at lines 562-565 — return without calling radeon_bo_kunmap(bo). The other switch cases (create/decode/ destroy) all kunmap before returning. The result is that the kernel leaves bo->kptr set and the underlying ttm_bo_kmap installed. Upstream Linux fixes this by moving radeon_bo_kunmap(bo) below the switch (with all per-case kunmaps removed); the DragonFlyBSD tree still carries the leak. A local attacker can submit crafted CS iocts that hit these paths repeatedly, keeping many BOs permanently kmapped and forcing the TTM layer to hold kernel virtual mappings it cannot reclaim on BO migration.

Root cause

At sys/dev/drm/radeon/radeon_uvd.c:489 r = radeon_bo_kmap(bo, &ptr); installs bo->kptr and bo->kmap.

Lines 500-503 (if (handle == 0) { DRM_ERROR(...); return -EINVAL; }) and lines 562-565 (default: DRM_ERROR(...); return -EINVAL;) return without ever calling radeon_bo_kunmap.

Contrast with case 0 (line 511), case 1 (line 537), case 2 (line 559) which all kunmap.

radeon_bo_kmap (radeon_object.c:270-291) is a one-shot per-BO map: if (bo->kptr) { *ptr = bo->kptr; return 0; } — there is no refcount, so a missing kunmap leaves the BO pinned into a kernel virtual address until something else explicitly releases it.

radeon_bo_kunmap (radeon_object.c:293-300) is what clears bo->kptr and calls ttm_bo_kunmap; without it, the kmap object persists across BO validation/migration, risking stale mappings.

Threat model

Attacker is a local user with render-node access. Submits a CS ioctl whose message BO has handle=0 (msg[2]=0) or an msg_type outside {0,1,2}. The kernel returns -EINVAL but leaves bo->kptr set. Repeated across many distinct BOs, this holds an unbounded number of kernel kmaps (each pinning a kernel virtual mapping and preventing clean BO migration).

Consequences range from slow kernel address-space pressure on 32-bit kernels to TTM misbehaviour when the still-kmapped BO is later moved by ttm_bo_validate. At minimum it is a local resource-exhaustion DoS; on configs where the stale kptr is later dereferenced against a migrated BO, a use-after-free-style stale kernel pointer read is conceivable. Also impacts correctness: any subsequent radeon_bo_kmap on the same BO short-circuits and returns the now-stale pointer.

PoC

Build a tiny C program against libdrm that opens /dev/dri/renderD128 (or card0 with auth), allocates a 256-byte BO via DRM_IOCTL_RADEON_GEM_CREATE, writes a UVD message into it via DRM_IOCTL_RADEON_GEM_PWRITE with msg[2]=0 (handle=0) so radeon_uvd_cs_msg hits line 500, and submits it through DRM_IOCTL_RADEON_CS on the UVD ring.

Loop allocating a fresh BO and re-submitting each iteration 100 000 times; the kernel's radeon_bo_kmap count climbs monotonically while no radeon_bo_kunmap is ever issued.

Detect: vmstat -m | grep ttm or via kgdb/truss on the kernel showing bo->kptr non-NULL on freed BOs. Expected log line per attempt: [drm:radeon_uvd_cs_msg] *ERROR* Invalid UVD handle!.

Build: cc -O2 -o uvdkmap_leak uvdkmap_leak.c -ldrm. Run: ./uvdkmap_leak. Success: dmesg shows 100K 'Invalid UVD handle' messages and kernel memory pressure rises; the leaked mappings outlive the BOs they reference.

Recommended fix

Move the kunmap out of each case and after the switch, matching upstream Linux.

--- a/sys/dev/drm/radeon/radeon_uvd.c
+++ b/sys/dev/drm/radeon/radeon_uvd.c
@@ -497,18 +497,14 @@ static int radeon_uvd_cs_msg(struct radeon_cs_parser *p, struct radeon_bo *bo,

    if (handle == 0) {
+       radeon_bo_kunmap(bo);
        DRM_ERROR("Invalid UVD handle!\n");
        return -EINVAL;
    }

    switch (msg_type) {
    case 0:
        /* it's a create msg, calc image size (width * height) */
        img_size = msg[7] * msg[8];

        r = radeon_uvd_validate_codec(p, msg[4]);
-       radeon_bo_kunmap(bo);
        if (r)
            return r;
@@ -532,7 +528,6 @@ static int radeon_uvd_cs_msg(struct radeon_cs_parser *p, struct radeon_bo *bo,
    case 1:
        /* it's a decode msg, validate codec and calc buffer sizes */
        r = radeon_uvd_validate_codec(p, msg[4]);
        if (!r)
            r = radeon_uvd_cs_msg_decode(msg, buf_sizes);
-       radeon_bo_kunmap(bo);
        if (r)
            return r;
@@ -553,9 +548,7 @@ static int radeon_uvd_cs_msg(struct radeon_cs_parser *p, struct radeon_bo *bo,
    case 2:
        /* it's a destroy msg, free the handle */
        for (i = 0; i < p->rdev->uvd.max_handles; ++i)
            atomic_cmpxchg(&p->rdev->uvd.handles[i], handle, 0);
-       radeon_bo_kunmap(bo);
        return 0;

    default:

        DRM_ERROR("Illegal UVD message type (%d)!\n", msg_type);
-       return -EINVAL;
-   }
-
-   BUG();
-   return -EINVAL;
+   }
+   radeon_bo_kunmap(bo);
+   return -EINVAL;
 }