• File: sys/dev/drm/radeon/atom.c
• Lines: 281, 284, 285, 286, 289, 540, 543, 544, 545, 547, 852, 856, 528
• Severity: High
• CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U:C:H/I:H/A:H
• CWE: CWE-787 Out-of-bounds Write
• Confidence: certain

Summary

The bounds check guarding FB (framebuffer scratch) accesses compares gctx->fb_base + (idx * 4) (computed in u32 arithmetic) against scratch_size_bytes.

Because fb_base is a fully attacker-controlled 32-bit value, choosing fb_base near 0xFFFFFFFF wraps the sum below scratch_size_bytes, bypassing the guard.

The subsequent scratch[] dereference at (fb_base/4)+idx is then a wild out-of-bounds heap read or write with an attacker-controlled value, offset, and alignment.

Root cause

In atom_get_src_int ATOM_ARG_FB (atom.c:281-292): idx = U8(*ptr) yields 0–255 (uint32_t idx, line 180).

The guard at line 284 is if ((gctx->fb_base + (idx * 4)) > gctx->scratch_size_bytes).

gctx->fb_base is uint32_t (atom.h:134) and is set to an arbitrary 32-bit value from the VBIOS by atom_op_setfbbase (atom.c:856: ctx->ctx->fb_base = atom_get_src(ctx, attr, ptr)) and by WS[ATOM_WS_FB_WINDOW] writes (atom.c:528: gctx->fb_base = val).

The addition fb_base + idx*4 is performed in uint32 arithmetic and silently wraps modulo 2^32.

When scratch_size_bytes (int, e.g. 20480) is converted to uint32 for the comparison, an attacker choosing fb_base=0xFFFFFFFC with idx=1 gets fb_base+4 = 0x100000000 → wraps to 0, and 0 > 20480 is false, so the guard is bypassed.

The actual access at line 289 gctx->scratch[(gctx->fb_base / 4) + idx] = scratch[0x3FFFFFFF + 1] is a wild OOB heap read.

The identical bug exists in atom_put_dst ATOM_ARG_FB (atom.c:540-549, write at line 547), giving a controlled heap OOB write: the written value val is fully controlled by preceding bytecode (e.g. a MOVE_IMM to FB).

The FB buffer (gctx->scratch) is kzalloc'd at atom.c:1424 with attacker-influenced size (from VBIOS VRAM_UsageByFirmware, default 20 KB).

Threat

Attacker delivers a crafted VBIOS.

The atom interpreter runs in kernel context during GPU init and every mode-set.

A VBIOS table issues SET_FB_BASE to load a near-0xFFFFFFFF value into fb_base, then a MOVE/MASK/ADD operation targeting FB[idx] writes an attacker-chosen 32-bit value at a controlled large offset past the scratch heap allocation.

This is a precise heap-corruption primitive (controlled address offset via fb_base, controlled index via idx, controlled value via source operand) that can overwrite adjacent kernel heap objects — function pointers, refcounts, or free-list metadata — enabling kernel code execution or privilege escalation.

Read variant leaks kernel heap contents.

Same threat vectors as the recursion finding (evil PCIe card auto-probed at boot; VM passthrough GPU with crafted VBIOS).

Exploit / PoC

Craft a VBIOS command table containing:

1. SET_FB_BASE (opcode 0x39, attr=IMM_DWORD) with immediate value 0xFFFFFFFC — this sets ctx->fb_base=0xFFFFFFFC;
2. MOVE_FB (opcode 0x04, attr encoding dst=FB/DWORD src=IMM/DWORD) with FB index byte 0x01 and an immediate source dword holding the desired overwrite value (e.g. an address of a gadget or a crafted function pointer).

On execution: the bounds check at atom.c:543 computes 0xFFFFFFFC + 4 = 0 (wrap) → 0 > 20480 is false → guard passes → scratch[(0xFFFFFFFC/4)+1] = scratch[0x40000000] writes the controlled dword ~16 GB past the scratch heap buffer.

For a DoS proof, use idx and fb_base such that the accessed address is unmapped → immediate kernel page-fault panic.

To demonstrate, build the crafted VBIOS as a flat binary, map it as the GPU ROM (or pass to a QEMU -device vfio-pci,romfile=evil.rom passthrough), boot, and observe the kernel panic during atom_asic_init.

For heap-grooming escalation, spray kernel heap objects of known layout adjacent to the scratch allocation, then use the controlled write to corrupt a victim object's function pointer.

Recommended fix

Validate fb_base independently of idx to prevent the wrap, and use overflow-safe arithmetic:

--- a/sys/dev/drm/radeon/atom.c
+++ b/sys/dev/drm/radeon/atom.c
@@ -281,9 +281,14 @@ static uint32_t atom_get_src_int(atom_exec_context *ctx, uint8_t attr,
    case ATOM_ARG_FB:
        idx = U8(*ptr);
        (*ptr)++;
-       if ((gctx->fb_base + (idx * 4)) > gctx->scratch_size_bytes) {
+       if (gctx->fb_base >= (uint32_t)gctx->scratch_size_bytes ||
+           (uint64_t)gctx->fb_base + (uint64_t)idx * 4 + 4 >
+               (uint64_t)gctx->scratch_size_bytes) {
            DRM_ERROR("ATOM: fb read beyond scratch region: %d vs. %d\n",
                  gctx->fb_base + (idx * 4), gctx->scratch_size_bytes);
            val = 0;
        } else
            val = gctx->scratch[(gctx->fb_base / 4) + idx];
@@ -540,9 +545,14 @@ static void atom_put_dst(atom_exec_context *ctx, int arg, uint8_t attr,
    case ATOM_ARG_FB:
        idx = U8(*ptr);
        (*ptr)++;
-       if ((gctx->fb_base + (idx * 4)) > gctx->scratch_size_bytes) {
+       if (gctx->fb_base >= (uint32_t)gctx->scratch_size_bytes ||
+           (uint64_t)gctx->fb_base + (uint64_t)idx * 4 + 4 >
+               (uint64_t)gctx->scratch_size_bytes) {
            DRM_ERROR("ATOM: fb write beyond scratch region: %d vs. %d\n",
                  gctx->fb_base + (idx * 4), gctx->scratch_size_bytes);
+       } else {
            gctx->scratch[(gctx->fb_base / 4) + idx] = val;
        }

The uint64 intermediate prevents 32-bit wrap, and the separate fb_base sanity check rejects out-of-range bases outright.

Related findings

• DF-1534 (sibling): unbounded recursion in atom_op_calltable.
• DF-1536 (sibling): unbounded PS operand index stack OOB.
• DF-1537 (sibling): unbounded WS operand index + NULL deref.