• File: sys/dev/drm/radeon/r600_dpm.c
• Lines: 1104, 1107, 1117, 1122, 1157, 1160, 834, 1003, 1046, 1189, 1247
• Severity: Medium
• CVSS: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U:C:L/I:N/A:H
• CWE: CWE-125 Out-of-bounds Read
• Confidence: likely

Summary

r600_parse_extended_power_table() derives every sub-table pointer from u16 offsets and u8 counts read directly out of the GPU VBIOS image (a kmalloc'd kernel heap buffer of ≤256 KB, see radeon_bios.c:68/98/153), and then walks ucNumEntries records or dereferences an ucVCEClockInfoIndex/ ucUVDClockInfoIndex without ever comparing those values against the actual remaining space in the BIOS buffer or against the corresponding array->ucNumEntries.

A malicious VBIOS (supplied by a hostile GPU, modified ROM, or virt passthrough) can drive the parser off the end of the BIOS allocation, producing a kernel heap OOB read that either panics the kernel (DoS) or leaks nearby kernel heap bytes into DPM state later observable through DPM debugfs/sysfs interfaces.

Root cause

The parser trusts every count/index field. Concrete instances:

1. r600_dpm.c:1104-1107 iterates limits->numEntries VCE limit records and for each dereferences array->entries[0] + entry->ucVCEClockInfoIndex * sizeof(VCEClockInfo) — ucVCEClockInfoIndex is UCHAR 0..255 (pptable.h:549) but is never compared to array->ucNumEntries (also UCHAR), so an index of 255 against a 1-entry array reads at +1530 B past array->entries[0]. Same pattern in the VCE state loop at r600_dpm.c:1117-1122 (state_entry->ucVCEClockInfoIndex) and the UVD loop at r600_dpm.c:1157-1160 (entry->ucUVDClockInfoIndex).

2. The generic table walkers — r600_parse_clk_voltage_dep_table at r600_dpm.c:833-840 (called from 927/936/947/959), phase-shedding at r600_dpm.c:1003-1012, CAC leakage at r600_dpm.c:1045-1062, VCE limits at 1104-1116, UVD at 1157-1169, SAMU at 1189-1196, ACP at 1247-1254 — each loop runs for (i = 0; i < ucNumEntries; i++) and advances a pointer by exactly sizeof(record) per iteration; nothing checks that &table->entries[0] + ucNumEntries*sizeof(record) still lies inside bios + bios_size.

The destination kzalloc at r600_dpm.c:829/993/1040/1095/1149/1181/1239 is correctly sized from the same ucNumEntries, so writes are safe — only the source reads from BIOS-backed memory are unbounded.

BIOS is read into a finite kmalloc buffer at radeon_bios.c:68/98/153 (≤256 KB) so a table placed near its end with a large ucNumEntries walks straight out of the heap object.

atom_parse_data_header() in atom.c:1366-1385 also does not bounds-check the idx it returns against bios_size, so data_offset itself is already untrusted.

Threat

Attacker position: anyone who can supply a crafted GPU VBIOS image — either a physically malicious PCIe GPU, an "evil maid" GPU swap, an IGP whose ROM is mirrored into VRAM (radeon_bios.c:47-76 igp_read_bios_from_vram), or a virtualization host presenting a forged ROM BAR / ATRM payload to a DragonFlyBSD guest with GPU passthrough.

No syscall or privilege is required: the radeon driver auto-attaches on device probe and calls r600_parse_extended_power_table() during DPM init.

Impact: kernel heap OOB read of up to ~255*sizeof(record) ≈ 1.5 KB per affected table, repeated across up to ~8 tables in one parse pass; the read either hits an unmapped page and panics (reliable local kernel DoS) or lands in another kmalloc slab and silently leaks those bytes into rdev->pm.dpm.* state (info disclosure of kernel heap to anyone who can later read DPM debug output).

Reachability is unconditional on driver attach for any R6xx-era Radeon with a malformed PowerPlay table.

Recommended fix

Add explicit bounds checks at every BIOS-derived table dereference. The minimal, targeted patch covers the most concrete (VCE/UVD index) and the broad (count) cases.

Compute the BIOS extent once and refuse tables whose declared extent exceeds it; check every index against its array's ucNumEntries.

--- a/sys/dev/drm/radeon/r600_dpm.c
+++ b/sys/dev/drm/radeon/r600_dpm.c
@@ -1100,6 +1114,14 @@ int r600_parse_extended_power_table(struct radeon_device *rdev)
            entry = &limits->entries[0];
            state_entry = &states->entries[0];
            for (i = 0; i < limits->numEntries; i++) {
+               if (entry->ucVCEClockInfoIndex >= array->ucNumEntries) {
+                   r600_free_extended_power_table(rdev);
+                   return -EINVAL;
+               }
                vce_clk = (VCEClockInfo *)
                    ((u8 *)&array->entries[0] +
                     (entry->ucVCEClockInfoIndex * sizeof(VCEClockInfo)));
@@ -1155,6 +1183,11 @@ int r600_parse_extended_power_table(struct radeon_device *rdev)
            entry = &limits->entries[0];
            for (i = 0; i < limits->numEntries; i++) {
+               if (entry->ucUVDClockInfoIndex >= array->ucNumEntries) {
+                   r600_free_extended_power_table(rdev);
+                   return -EINVAL;
+               }
                UVDClockInfo *uvd_clk = (UVDClockInfo *)
                    ((u8 *)&array->entries[0] +
                     (entry->ucUVDClockInfoIndex * sizeof(UVDClockInfo)));

A more thorough fix would also pass the BIOS base+length into every table parser and validate &atom_table->entries[0] + ucNumEntries*sizeof(record) <= bios_end before each loop (the same way mainline Linux drm/radeon gained such helpers in later revisions).

Related findings

• DF-1468/1469/1470 (siblings, processpptables.c): VBIOS PowerPlay parser OOB family.
• DF-1534-1537 (siblings, radeon/atom.c): atom interpreter OOB family.
• DF-1542-1545 (siblings, amdgpu/atom.c): amdgpu atom interpreter OOB family.
• DF-1496/1498 (siblings, ppatomctrl.c): VBIOS SMU/Profiling table OOB.
• Part of the recurring "VBIOS offset/index OOB" family.