• File: sys/dev/drm/amd/amdgpu/atom.c
• Lines: 222, 223, 256, 493, 494, 523, 1222, 1223, 1225
• Severity: Medium
• CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U:C:N/I:H/A:H
• CWE: CWE-476 NULL Pointer Dereference
• Confidence: certain

Summary

The WS (workspace) operand indexes ctx->ws[idx] with idx = U8(*ptr) (0-255) but ws is heap-allocated to only ws dwords as declared in the table header (atom.c:1223).

When the table declares ws=0, ectx.ws is set to NULL (atom.c:1225) and any WS access dereferences NULL → guaranteed kernel panic.

When ws>0, idx >= ws is a heap out-of-bounds read (info leak) or write (heap corruption) with attacker-controlled value.

Root cause

amdgpu_atom_execute_table_locked reads ws from the VBIOS table header: ws = CU8(base + ATOM_CT_WS_PTR) (atom.c:1210, range 0-255).

At atom.c:1222-1225:

if (ws) ectx.ws = kcalloc(4, ws, GFP_KERNEL);
else    ectx.ws = NULL;

(the kcalloc(4, ws, ...) form allocates 4*ws bytes = ws dwords).

The WS operand handlers then index ctx->ws[idx] where idx = U8(*ptr) (atom.c:223 in atom_get_src_int, atom.c:494 in atom_put_dst) — with NO check that idx < ws.

The default case in atom_get_src_int (atom.c:255-257: val = ctx->ws[idx];) and atom_put_dst (atom.c:522-524: ctx->ws[idx] = val;) are reached for all idx not matching the special ATOM_WS_* range (0x40-0x48, atom.h:88-96).

Case 1 (ws=0): ectx.ws is NULL (atom.c:1225); any WS opcode (e.g. MOVE_WS, opcode 0x03 in opcode_table at atom.c:1072) hits ctx->ws[idx] = NULL[idx], dereferencing a near-zero address → immediate page-fault panic.

Case 2 (ws=N>0): the allocation is 4*N bytes; idx >= N reads/writes past the heap allocation. idx=255 with ws=1 writes at offset 1020 past a 4-byte allocation — a heap overflow with attacker-controlled value (val from source operand) and offset (idx from bytecode).

Threat

Case 1 (ws=0 + WS access) is the simplest reliable kernel DoS: a VBIOS table declaring WS=0 in its header but containing any WS-operand opcode (MOVE_WS, ADD_WS, etc.) triggers an unconditional NULL-pointer-dereference panic during GPU init or mode-set.

No heap grooming needed.

Case 2 (ws>0 + large idx) is a heap-corruption primitive analogous to the FB finding: controlled write at controlled offset past a small heap allocation, enabling adjacent-object overwrite for privilege escalation with heap grooming.

Threat vectors identical to the other findings (evil PCIe card auto-probed at boot; VM passthrough with crafted VBIOS = guest-to-host escape).

Severity is Medium primarily because the most reliable impact is DoS (panic); the heap-overflow escalation requires more setup but is fully achievable.

Exploit / PoC

Case 1 (NULL deref panic): craft a VBIOS command table with header byte at ATOM_CT_WS_PTR (offset 4) = 0x00 (ws=0).

Bytecode: MOVE_WS — opcode 0x03 (opcode_table at atom.c:1072), attr byte with low 3 bits = ATOM_ARG_WS=2 and bits[5:3]=ATOM_SRC_DWORD=0, followed by WS index byte 0x00, then source IMM dword 0x00000000.

On execution: ectx.ws = NULL (atom.c:1225), opcode handler calls atom_get_dst → atom_get_src_int WS case → default (atom.c:256) → ctx->ws[0] = NULL[0] → dereference address 0 → kernel page-fault panic.

Trigger via amdgpu_atom_asic_init at boot (atom.c:1369).

Success = immediate panic with null-deref in atom_get_src_int.

Case 2 (heap OOB write): set header WS=0x01 (allocates 4 bytes), bytecode MOVE_WS with WS index 0x80 and source value = controlled dword → writes at offset 0x200 past the 4-byte heap slab.

For escalation, groom the slab (e.g. via display-mode ioctls that allocate same-size objects) to place a victim object adjacent, then overwrite its function pointer.

PoC: small C tool that synthesizes the VBIOS byte image; cc -o evil_vbios evil_vbios.c on DragonFlyBSD, supply via qemu -device vfio-pci,romfile=evil.rom.

Recommended fix

Validate idx against the allocated ws size, and refuse to execute WS operands when ws=0:

--- a/sys/dev/drm/amd/amdgpu/atom.c
+++ b/sys/dev/drm/amd/amdgpu/atom.c
@@ -55,6 +55,7 @@ typedef struct {
    struct atom_context *ctx;
    uint32_t *ps, *ws;
    int ps_shift;
+   int ws_size;          /* allocated dwords in ws[], 0 if none */
    uint16_t start;
@@ -253,6 +254,11 @@ static uint32_t atom_get_src_int(atom_exec_context *ctx, uint8_t attr,
        case ATOM_WS_REGPTR:
            val = gctx->reg_block;
            break;
        default:
+           if (!ctx->ws || idx >= ctx->ws_size) {
+               DRM_ERROR("ATOM: WS read index %u out of range (ws=%d)\n",
+                     idx, ctx->ws_size);
+               return 0;
+           }
            val = ctx->ws[idx];
        }
@@ -520,6 +526,11 @@ static void atom_put_dst(atom_exec_context *ctx, int arg, uint8_t attr,
        case ATOM_WS_REGPTR:
            gctx->reg_block = val;
            break;
        default:
+           if (!ctx->ws || idx >= ctx->ws_size) {
+               DRM_ERROR("ATOM: WS write index %u out of range (ws=%d)\n",
+                     idx, ctx->ws_size);
+               break;
+           }
            ctx->ws[idx] = val;
@@ -1222,6 +1233,7 @@ static int amdgpu_atom_execute_table_locked(struct atom_context *ctx, int index,
    if (ws)
        extx.ws = kcalloc(4, ws, GFP_KERNEL);
    else
        extx.ws = NULL;
+   extx.ws_size = ws;

Related findings

• DF-1537 (twin, radeon/atom.c): identical defect in the radeon copy.
• DF-1542/DF-1543/DF-1544 (siblings): other atom interpreter OOB family in this file.