• File: sys/dev/drm/radeon/atom.c
• Lines: 624, 633, 634, 635, 1163, 1171, 1192, 1206
• 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 atom_execute_table_locked with no depth limit.

A crafted VBIOS command table whose first opcode is 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, if no guard page exists, a stack-smash into an adjacent thread stack or return-address overwrite.

Root cause

atom_op_calltable (atom.c:624-638) reads a table index from the VBIOS byte stream (idx = U8 at line 626, range 0–255) and, if the corresponding cmd_table entry is non-zero (line 633: if (U16(ctx->ctx->cmd_table + 4 + 2 * idx))), calls atom_execute_table_locked(ctx->ctx, idx, ctx->ps + ctx->ps_shift) at line 634.

atom_execute_table_locked (atom.c:1163-1222) has NO recursion-depth parameter or guard.

The only depth-related variable is the file-scope debug_depth (atom.c:87), which is used solely for print indentation (atom.c:96, 1192, 1215) and never aborts execution.

Each recursion frame carries the atom_exec_context struct (~48 bytes), local ints (base/len/ws/ps/ptr/op/ret), plus the opcode-handler and atom_op_calltable stack frames — conservatively 150–250 bytes per level.

At ~16 KB kernel stack depth, 60–100 levels of recursion overflow the stack.

A self-referential table (table[idx] contains CALL_TABLE idx as its first opcode) recurses until the stack is exhausted.

The existing 5-second loop watchdog (atom.c:733-740 in atom_op_jump) does NOT protect against recursion because each level gets a fresh ectx with last_jump=0; the abort flag propagates only after a return, by which point the stack is already overflowed.

Threat

Attacker delivers a malicious VBIOS image.

Realistic vectors:

• (a) an evil PCIe GPU card auto-probed by the host at boot or hot-plug — the radeon driver calls atom_asic_init (atom.c:1331) unconditionally during radeon_atombios_init / device probe, executing the attacker's bytecode in kernel context with no host privileges required beyond physical insertion;
• (b) a VM with GPU passthrough whose VBIOS blob is supplied from an untrusted host configuration file, triggered by any guest display operation (mode set, encoder control) that calls atom_execute_table (e.g. atombios_crtc.c:77).

Impact ranges from reliable kernel panic (A:H DoS) to potential kernel code execution if the stack overflow overwrites a 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, starting with 0x55 0xAA magic at offset 0, ' 761295520' at offset 0x30, 'ATOM' at the ROM table).

Set ROM_TABLE.cmd_table to point to a command-table directory with entry [0] non-zero.

Define command table 0 with header WS=0, PS=0, then a single opcode byte 0x4F (CALL_TABLE, opcode index from atom-names.h:79) followed by operand byte 0x00 (call table 0).

This creates immediate infinite self-recursion: atom_execute_table_locked(ctx,0,...) → opcode 0x4F → atom_op_calltable reads idx=0, sees cmd_table[0] non-zero → atom_execute_table_locked(ctx,0,...) → repeat until kernel stack exhaustion.

Trigger: load on a system with a radeon GPU and replace the VBIOS, or boot a VM whose passthrough GPU uses this crafted VBIOS.

The kernel panics with a stack overflow / double fault during radeon device probe (atom_asic_init at atom.c:1347) or during the first mode-set.

Success = immediate kernel panic (stack exhaustion) confirmed via dmesg 'fatal double fault' or 'stack overflow' message; RIP control is achievable by padding the recursion depth so the overflow lands on a saved return address with a controlled value threaded through the ectx locals.

Recommended fix

Add a recursion-depth counter to struct atom_context (atom.h) and reject deep recursion in atom_execute_table_locked. The counter must be decremented on every return path including the error/abort paths.

--- a/sys/dev/drm/radeon/atom.h
+++ b/sys/dev/drm/radeon/atom.h
@@ -138,6 +138,7 @@ struct atom_context {
    uint8_t shift;
    int cs_equal, cs_above;
    int io_mode;
+   int recursion_depth;
    uint32_t *scratch;
    int scratch_size_bytes;
 };
--- a/sys/dev/drm/radeon/atom.c
+++ b/sys/dev/drm/radeon/atom.c
@@ -1163,6 +1163,12 @@ static int atom_execute_table_locked(struct atom_context *ctx, int index, uint32
    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;

    len = CU16(base + ATOM_CT_SIZE_PTR);
@@ -1216,6 +1222,7 @@ static int atom_execute_table_locked(struct atom_context *ctx, int index, uint32
    ATOM_SDEBUG_PRINT("<<\n");

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

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

Related findings

• DF-1535 (sibling): integer overflow in FB scratch bounds check.
• DF-1536 (sibling): unbounded PS operand index stack OOB.
• DF-1537 (sibling): unbounded WS operand index + NULL deref.