• File: sys/dev/drm/amd/amdgpu/atom.c
• Lines: 610, 612, 619, 620, 622, 623, 1198, 1206, 1228, 1253
• Severity: High
• CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U:C:H/I:H/A:H
• CWE: CWE-674 Uncontrolled Recursion
• Confidence: certain

Summary

The ATOM CALL_TABLE opcode atom_op_calltable recurses into amdgpu_atom_execute_table_locked with no recursion-depth guard.

A crafted VBIOS command table whose bytecode contains CALL_TABLE pointing at itself (or a cycle of tables) drives unbounded recursion, exhausting the ~16 KB kernel stack and producing a kernel panic, or a stack-smash into an adjacent thread stack / saved return address.

Root cause

atom_op_calltable (atom.c:610-624) reads a table index from the VBIOS byte stream (idx = U8((*ptr)++) at atom.c:612, range 0-255) and, if the corresponding cmd_table entry is non-zero (atom.c:619: if (U16(ctx->ctx->cmd_table + 4 + 2 * idx))), calls r = amdgpu_atom_execute_table_locked(ctx->ctx, idx, ctx->ps + ctx->ps_shift); at atom.c:620.

amdgpu_atom_execute_table_locked (atom.c:1198-1257) has NO recursion-depth parameter or guard: it just reads the table header (atom.c:1209-1212), allocates a fresh ectx.ws (atom.c:1222-1225), bumps the file-scope debug_depth (atom.c:1227) which is used solely for printk indentation (atom.c:88-95), and runs the dispatch loop (atom.c:1228-1249).

Each frame carries atom_exec_context (~48 bytes, atom.c:55-63) plus locals base/len/ws/ps/ptr/op/ret.

The 5-second loop watchdog in atom_op_jump (atom.c:740-751) does NOT protect against recursion: each level gets a fresh ectx with last_jump=0 (atom.c:1221) and the abort flag (atom.c:622-623, set when the recursive call returns non-zero) only fires after the stack is already exhausted.

At ~16 KB stack and ~150-250 bytes per level, 60-100 levels suffice to overflow.

A self-referential table (table[idx] begins with CALL_TABLE idx) recurses indefinitely.

Threat

Attacker delivers a malicious VBIOS image.

Realistic vectors:

• (a) an evil PCIe AMD GPU auto-probed by the host at boot or hot-plug — amdgpu_atom_asic_init (atom.c:1354) calls amdgpu_atom_execute_table(ATOM_CMD_INIT) unconditionally during amdgpu device probe, executing attacker bytecode in kernel context with no host privilege beyond physical insertion;
• (b) a VM with GPU passthrough whose VBIOS blob is supplied from an untrusted host config and triggered by any guest display op (mode set, encoder control, DP aux) that calls amdgpu_atom_execute_table (e.g. atombios_crtc.c:81,110, 127,143,159,175,187,232,297,398,431,518,548,744; atombios_encoders.c:414,511,817,1242,1270,1394,1739,1812; atombios_dp.c:85,307; atombios_i2c.c:94,180; amdgpu_atombios.c:1037,1057,1075,1086,1127,1169).

Impact ranges from reliable kernel panic (A:H DoS) to RIP control if the stack overflow overwrites a saved return address (C:H/I:H).

Because the atom interpreter runs under the host kernel, a VM-passthrough scenario is a guest-to-host escape vector.

Exploit / PoC

Craft a minimal VBIOS image (>=512 bytes):

• offset 0 = 0x55 0xAA (ATOM_BIOS_MAGIC, atom.h:31);
• offset 0x30 = ' 761295520' (ATOM_ATI_MAGIC, atom.h:33);
• offset 0x48 → ROM_TABLE whose offset+4 = 'ATOM' (atom.h:37);
• ROM_TABLE.cmd_table (atom.h:41) points to a command-table directory with entry [0] non-zero.

Define command table 0 with header bytes WS=0 (offset ATOM_CT_WS_PTR=4), PS=0 (offset 5), then opcode byte 0x4F (ATOM_OP_CALLTABLE, index 0x4F in opcode_table at atom.c:1151) followed by operand byte 0x00 (call table 0).

Result: amdgpu_atom_execute_table_locked(ctx,0,...) → opcode 0x4F → atom_op_calltable reads idx=0 (atom.c:612), sees cmd_table[0] non-zero (atom.c:619) → amdgpu_atom_execute_table_locked(ctx,0,...) → repeat until kernel stack exhaustion.

Trigger: boot the host with the evil AMD GPU inserted, or boot a VM whose passthrough GPU uses this crafted VBIOS.

The kernel panics with a stack-overflow/double-fault during amdgpu_atom_asic_init (atom.c:1369).

Success = fatal double fault / stack overflow in dmesg during GPU probe.

PoC source: a small userland tool that synthesizes the byte image and writes it to the romfile used by qemu -device vfio-pci,romfile=evil.rom (or a PCIe BAR1 VBIOS override).

Build on DragonFlyBSD with cc -o evil_vbios evil_vbios.c.

Recommended fix

Add a recursion-depth counter to struct atom_context and reject deep recursion in amdgpu_atom_execute_table_locked, decrementing on every return path.

--- a/sys/dev/drm/amd/amdgpu/atom.h
+++ b/sys/dev/drm/amd/amdgpu/atom.h
@@ -136,7 +136,8 @@ struct atom_context {
    uint8_t shift;
    int cs_equal, cs_above;
    int io_mode;
+   int recursion_depth;
    uint32_t *scratch;
--- a/sys/dev/drm/amd/amdgpu/atom.c
+++ b/sys/dev/drm/amd/amdgpu/atom.c
@@ -1198,6 +1198,12 @@ static int amdgpu_atom_execute_table_locked(struct atom_context *ctx, int index,
    atom_exec_context ectx;
    int ret = 0;

+   if (ctx->recursion_depth > 20) {
+       DRM_ERROR("ATOM: command table recursion limit exceeded (table %d)\n", index);
+       return -EINVAL;
+   }
+   ctx->recursion_depth++;
+
    if (!base)
-       return -EINVAL;
+       goto out_depth;

@@ -1250,9 +1256,12 @@ static int amdgpu_atom_execute_table_locked(struct atom_context *ctx, int index,
    SDEBUG("<<\n");

 free:
+   ctx->recursion_depth--;
    kfree(ectx.ws);
    return ret;
+out_depth:
+   ctx->recursion_depth--;
+   return -EINVAL;
 }

A depth limit of 20 bounds stack usage to roughly 5 KB worst case, well within the 16 KB kernel stack. Upstream Linux adopted the same approach.

Related findings

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