Summary

In cik_copy_dma(), the total transfer size is computed as size_in_bytes = (num_gpu_pages << RADEON_GPU_PAGE_SHIFT) where size_in_bytes is declared u32 (line 586) and RADEON_GPU_PAGE_SHIFT is 12 (radeon.h:645). When num_gpu_pages >= 0x100000 (a 4 GB or larger buffer object), the shift overflows the 32-bit variable to a small or zero value. num_loops is then computed from this wrapped value, causing zero or partial SDMA copy commands to be emitted, while the fence still signals completion and TTM marks the buffer move as done. The destination buffer silently retains stale memory contents instead of the source data.

Root cause

At cik_sdma.c:586, both size_in_bytes and cur_size_in_bytes are declared as u32. At line 592:

size_in_bytes = (num_gpu_pages << RADEON_GPU_PAGE_SHIFT);

The parameter num_gpu_pages is unsigned (32-bit, line 579), and RADEON_GPU_PAGE_SHIFT=12.

For a 4 GB BO, the caller radeon_ttm_move_blit (radeon_ttm.c:301-302) passes num_pages = new_mem->num_pages * (PAGE_SIZE/RADEON_GPU_PAGE_SIZE) = 0x100000 * 1 = 0x100000. The expression 0x100000 << 12 = 0x100000000 wraps to 0 in u32 arithmetic. Then num_loops = DIV_ROUND_UP(0, 0x1fffff) = 0 (line 593), the for-loop at line 604 does not execute, no SDMA COPY packets are emitted, but radeon_fence_emit (line 620) and radeon_ring_unlock_commit (line 627) proceed normally. The caller ttm_bo_move_accel_cleanup (radeon_ttm.c:306) updates buffer placement metadata as if the move succeeded.

The same overflow pattern exists for any BO ≥ 4 GB: e.g. a 6 GB BO (num_gpu_pages=0x180000) wraps size_in_bytes to 0x80000000 (2 GB), copying only 2 GB of 6 GB.

This bug exists identically in r600.c:2988, si_dma.c:246, cik.c:3686, evergreen_dma.c:121, and rv770_dma.c:57 — all use u32 size variables with the same shift.

Threat model

An unprivileged local user with access to /dev/dri/card0 (standard for desktop users in the video group) on a system with a CIK-era radeon GPU having 4 GB+ VRAM (e.g. Hawaii / R9 290, R9 390) can trigger this.

The user allocates a ≥ 4 GB buffer object (RADEON_GEM_CREATE ioctl, radeon_gem.c:255) and causes a domain move (via CS ioctl validation path radeon_cs_ioctl → radeon_bo_list_validate → ttm_bo_validate, or via TTM memory-pressure eviction). The move calls cik_copy_dma with the overflowing num_gpu_pages.

Impact:

1. Data corruption — the destination contains stale data instead of source contents, corrupting GPU rendering or compute.
2. Cross-user info leak — VRAM pages are not zeroed on free (radeon VRAM pool reuse), so if the destination region previously held another user's buffer, the attacker reads that user's stale GPU data by mapping and reading the destination BO.
3. Potential GPU hang if corrupted buffer is used as a command stream.

PoC

findings/poc/DF-1672/:

1. Open /dev/dri/card0 (requires video group membership).
2. Allocate a 4 GB BO in VRAM: ioctl(fd, DRM_IOCTL_RADEON_GEM_CREATE, &args) where args.size = 0x100000000ULL, args.initial_domain = RADEON_GEM_DOMAIN_VRAM. This requires 4 GB+ free VRAM.
3. Fill the BO with a known pattern (e.g. 0x41414141) by mmap-ing it and writing, or by submitting a CS that writes to it.
4. Trigger a domain move from VRAM to GTT. On DragonFlyBSD, RADEON_GEM_SET_DOMAIN is a stub (radeon_gem.c:96-131 "FIXME: reeimplement"), so use the CS path: submit a command stream (DRM_IOCTL_RADEON_CS) that references the BO with RADEON_GEM_DOMAIN_GTT in the relocation list. This calls radeon_bo_list_validate → ttm_bo_validate → radeon_bo_move → radeon_ttm_move_blit → cik_copy_dma(rdev, old_start, new_start, 0x100000, bo->resv). Inside cik_copy_dma: size_in_bytes = 0x100000 << 12 = 0 (overflow), num_loops = 0, no copy emitted.
5. Map the BO in GTT and read its contents. Expected: all 0x41414141. Actual: stale VRAM data (whatever was in the destination GTT/VRAM pages before the move).

Success criterion: the BO contents after the move do NOT match the known pattern written before the move.

For an info-leak variant: a second user (victim) allocates a BO, fills with sensitive data, frees it; the attacker's 4 GB BO move lands on the victim's freed pages, and the attacker reads stale victim data.

For a simpler reproduction that avoids the 4 GB VRAM requirement: allocate a BO of size 0x100001 * 4096 (4 GB + 4 KB), which wraps size_in_bytes to 0x1000 (4096) — only the first 4 KB is copied, the rest is stale.

Recommended fix

Change size_in_bytes and cur_size_in_bytes from u32 to u64 and cast num_gpu_pages to u64 before the shift. The rest of the code (capping cur_size_in_bytes at 0x1fffff, ring writes, offset increments) works correctly with 64-bit types since the per-iteration cap fits in u32 and radeon_ring_write takes uint32_t.

--- a/sys/dev/drm/radeon/cik_sdma.c
+++ b/sys/dev/drm/radeon/cik_sdma.c
@@ -583,8 +583,8 @@ struct radeon_fence *cik_copy_dma(struct radeon_device *rdev,
    int ring_index = rdev->asic->copy.dma_ring_index;
    struct radeon_ring *ring = &rdev->ring[ring_index];
-   u32 size_in_bytes, cur_size_in_bytes;
+   u64 size_in_bytes, cur_size_in_bytes;
    int i, num_loops;
    int r = 0;

    radeon_sync_create(&sync);

-   size_in_bytes = (num_gpu_pages << RADEON_GPU_PAGE_SHIFT);
+   size_in_bytes = (u64)num_gpu_pages << RADEON_GPU_PAGE_SHIFT;
    num_loops = DIV_ROUND_UP(size_in_bytes, 0x1fffff);
    r = radeon_ring_lock(rdev, ring, num_loops * 7 + 14);
@@ -604,7 +604,7 @@ struct radeon_fence *cik_copy_dma(struct radeon_device *rdev,
        cur_size_in_bytes = size_in_bytes;
        if (cur_size_in_bytes > 0x1fffff)
            cur_size_in_bytes = 0x1fffff;
        size_in_bytes -= cur_size_in_bytes;
        radeon_ring_write(ring, SDMA_PACKET(SDMA_OPCODE_COPY, SDMA_COPY_SUB_OPCODE_LINEAR, 0));
-       radeon_ring_write(ring, cur_size_in_bytes);
+       radeon_ring_write(ring, (u32)cur_size_in_bytes);
        radeon_ring_write(ring, 0); /* src/dst endian swap */

The same u32 → u64 fix should be applied to the equivalent copy functions in r600.c:2988, si_dma.c:246, cik.c:3686, evergreen_dma.c:121, and rv770_dma.c:57, which all share the identical overflow pattern. Additionally, num_loops (declared int) should be checked for overflow if num_loops * 7 exceeds the ring's maximum allocation, though for realistic BO sizes (< 16 GB) num_loops stays under 8192 and 8192*7=57344 fits in int.