⬢ DragonFlyBSD Kernel Audit
← triage · dashboard
DF-1497

Missing NULL check on voltage_object in atomctrl_get_svi2_info dereferences lookup result

Summary

atomctrl_get_svi2_info() calls atomctrl_lookup_voltage_type_v3() which explicitly returns NULL when no voltage object matches the requested (voltage_type, VOLTAGE_OBJ_SVID2) pair (ppatomctrl.c:238).

The caller dereferences voltage_object->asSVID2Obj.ucSVDGpioId / ucSVCGpioId / usLoadLine_PSI at lines 1447–1449 without any NULL check, causing a kernel NULL-deref panic. Reached unconditionally on CHIP_POLARIS12 / kicker parts during smu7_hwmgr init.

Root cause

ppatomctrl.c:1441-1442 guards only voltage_info (the table) with PP_ASSERT_WITH_CODE. ppatomctrl.c:1444-1445 then sets

voltage_object = atomctrl_lookup_voltage_type_v3(
    voltage_info, voltage_type, VOLTAGE_OBJ_SVID2);

atomctrl_lookup_voltage_type_v3 (ppatomctrl.c:219-239) walks the voltage objects and returns NULL if none has ucVoltageMode==VOLTAGE_OBJ_SVID2 for the given ucVoltageType.

ppatomctrl.c:1447 immediately does *svd_gpio_id = voltage_object->asSVID2Obj.ucSVDGpioId; — asSVID2Obj lives at offset 0 within the ATOM_VOLTAGE_OBJECT_V3 union (atombios.h:5219-5225), so a NULL voltage_object reads near address 0x0+offsetof(asSVID2Obj).

No other caller-side guard exists: smu7_hwmgr.c:1593-1597 invokes atomctrl_get_svi2_info(hwmgr, VOLTAGE_TYPE_VDDC, &tmp1, &tmp2, &tmp3) with no return-value inspection (the function returns int but the caller ignores it).

Threat

Local, kernel-context, on the amdgpu driver-load path for CHIP_POLARIS12 or any SMU7 kicker part (smu7_hwmgr.c:1593 if (hwmgr->chip_id == CHIP_POLARIS12 || hwmgr->is_kicker)).

Precondition: VBIOS VoltageObjectInfo table lacks an SVID2-mode object for VOLTAGE_TYPE_VDDC (a forged/trimmed VBIOS, or a legitimate VBIOS variant where the SVID2 object was omitted).

Impact: deterministic kernel NULL-pointer-dereference panic during init → local DoS (driver load failure / system hang on GPU-bound boot).

CVSS reflects A:H only (no confidentiality/integrity impact — pure crash).

Exploit / PoC

Forge a VBIOS whose VoltageObjectInfo (DATA, VoltageObjectInfo) atom table contains zero ATOM_SVID2_VOLTAGE_OBJECT_V3 entries (i.e. every object's sHeader.ucVoltageMode != VOLTAGE_OBJ_SVID2, or omit the table's SVID2 object).

Flash to a POLARIS12 GPU or inject via SR-IOV atom_context. On amdgpu bind, smu7_hwmgr.c:1596 calls atomctrl_get_svi2_info → atomctrl_lookup_voltage_type_v3 returns NULL at ppatomctrl.c:238 → ppatomctrl.c:1447 dereferences NULL → kernel panic fatal trap 12: page fault while in kernel mode at NULL+offset.

Success = panic on driver load.

Check voltage_object for NULL and return -EINVAL before dereferencing, consistent with the existing voltage_info guard.

--- a/sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.c
+++ b/sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.c
@@ -1444,6 +1444,9 @@ int  atomctrl_get_svi2_info(struct pp_hwmgr *hwmgr, uint8_t voltage_type,
    voltage_object = atomctrl_lookup_voltage_type_v3
        (voltage_info, voltage_type,  VOLTAGE_OBJ_SVID2);

+   if (voltage_object == NULL)
+       return -EINVAL;
+
    *svd_gpio_id = voltage_object->asSVID2Obj.ucSVDGpioId;
    *svc_gpio_id = voltage_object->asSVID2Obj.ucSVCGpioId;
  • DF-1496, DF-1498 (siblings): same file's other VBIOS-parser defects.

Discussion (0)

No comments yet.

PoC verification

Evidence pack

findings/poc/DF-1497 · 10 files
FileTypeDescriptionSize
README.md readme human-readable summary 1.7 KB ↓ raw
VERDICT.md verdict full source-level analysis + fix-validation result 2.7 KB ↓ raw
fix.diff suggested-fix git-apply-able minimal fix; compiles -Werror clean 558 B view raw
build.sh build-script echoes the module/kernel rebuild command 393 B view raw
run.sh run-script no live trigger on this guest 307 B view raw
env.txt environment guest uname, modules loaded, HW-gated note 344 B view raw
build.log build-log kernel build log excerpt proving -Werror clean compile of patched source 402 B view raw
fix_apply.log apply-log patch --dry-run output proving fix.diff applies cleanly on with-src 300 B view raw
../fix_build_combined.log build-log Combined 41-finding kernel build (rc=0, -Werror clean) 5.6 MB ↓ download
../fix_build_summary.txt build-summary Summary of the combined 41-finding kernel build 826 B view raw
README.md readme human-readable summary
↓ download raw

PoC DF-1497: ppatomctrl_get_svi2_voltage_object GPU NULL deref

Class: NULL pointer dereference (DoS) Cited site: sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.c:1444-1449

Reproduction status

HW/module gated — cannot be live-triggered on the audit QEMU guest.

No — amdgpu powerplay HW-gated. Trigger requires a GPU VBIOS with no SVID2 voltage object matching the requested voltage_type.

The bug is confirmed at the source level by tracing the cited path:line in sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.c and confirming the vulnerable code is present in the master DEV kernel tree. The fix.diff in this folder is validated to apply cleanly and compile under -Werror (see VERDICT.md).

Mechanism

Line 1441-1442 only guards voltage_info (the table) — that pointer is checked. Line 1444-1445 voltage_object = atomctrl_lookup_voltage_type_v3(...) returns NULL at ppatomctrl.c:238 when no voltage object matches (voltage_type, VOLTAGE_OBJ_SVID2). Lines 1447-1449 unconditionally deref voltage_object->asSVID2Obj.ucSVDGpioId/ucSVCGpioId/usLoadLine_PSI → NULL deref → kernel panic.

Realistic impact ceiling

panic (DoS)

Fix

Add if (voltage_object == NULL) return -EINVAL; between the lookup and the first deref.

See fix.diff for the git-apply-able patch.

How to validate the fix

# 1. Apply fix.diff against the in-guest source:
scp -F dfbsd-qemu/config fix.diff dfbsd:/root/DF-1497.diff
ssh -F dfbsd-qemu/config dfbsd 'cd /usr/src && patch -p1 < /root/DF-1497.diff'

# 2. Rebuild the affected module (preferred) or a single-fix kernel:
ssh -F dfbsd-qemu/config dfbsd 'cd /usr/src/sys/sys/dev/drm/amd/powerplay/hwmgr && make'

# 3. The compile must succeed with -Werror (it does — see build.log).
VERDICT.md verdict full source-level analysis + fix-validation result
↓ download raw

VERDICT — DF-1497: ppatomctrl_get_svi2_voltage_object GPU NULL deref

Verdict

INCONCLUSIVE (HW/module gated) — source-level confirmed, fix validated.

The bug is real and present in master DEV source at sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.c:1444-1449, but the affected driver attaches only to hardware not present in the audit QEMU guest, so it cannot be live-triggered here. The fix.diff applies cleanly and compiles with -Werror (kernel build rc=0; see fix_build.log).

Mechanism (cited path → primitive → effect)

Line 1441-1442 only guards voltage_info (the table) — that pointer is checked. Line 1444-1445 voltage_object = atomctrl_lookup_voltage_type_v3(...) returns NULL at ppatomctrl.c:238 when no voltage object matches (voltage_type, VOLTAGE_OBJ_SVID2). Lines 1447-1449 unconditionally deref voltage_object->asSVID2Obj.ucSVDGpioId/ucSVCGpioId/usLoadLine_PSI → NULL deref → kernel panic.

Reachability on this guest

No — amdgpu powerplay HW-gated. Trigger requires a GPU VBIOS with no SVID2 voltage object matching the requested voltage_type.

Phase 6 — escalation potential

This is a NULL pointer dereference (DoS) primitive. On real hardware it could be triggered by an unprivileged user (via crafted packets for the NIC findings, via DRM ioctls for the GPU findings, via CAM/pass for the SCSI findings). On this guest there is no live primitive to convert. Per Phase 6 rules this is the "dead/unreachable at runtime on this guest" hard blocker; the primitive is proven at the source/harness level (the cited path:line is real and unfixed in master).

For findings in this batch that are corruption-class on hardware they would be live-tested on (NIC cards, RAID HBAs, AMD/Intel GPUs), the realistic escalation ceiling is documented per finding (info-leak vs DoS vs latent privesc). No uid=0 claim is made — none is reachable on this guest.

Phase 8 — fix validation

fix.diff is a minimal, targeted fix at the root cause confirmed above.

  • Applied cleanly with patch -p1 --forward (verified in fix_apply.log).
  • Compiled with -Werror as part of make -j6 nativekernel KERNCONF=X86_64_GENERIC (kernel build rc=0; affected module builds radeon.ko/amdgpu.ko/sound.ko/i915.ko/vga_switcheroo.ko all produced).
  • For musycc.c (not in any default config) the file was compiled standalone with the kernel -Werror cflags — rc=0.

Add if (voltage_object == NULL) return -EINVAL; between the lookup and the first deref.

PoC changes

Source-level confirmation only; no userspace harness written because the bug cannot be exercised on this guest without the relevant HW. The placeholder build.sh/run.sh echo pointers to VERDICT.md and the module/kernel rebuild path.

Confirmed kernel references

Detail

Exploit chain

none — amdgpu HW-gated (no AMD GPU in guest). Primitive is NULL-deref panic on real HW; no live escalation possible on this guest.

Evidence (decisive lines)

Source-level confirmation at sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.c:1444, sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.c:1447, sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.c:238. fix.diff applies cleanly (patch -p1 --forward: APPLIES_OK) and compiles -Werror clean as part of `make -j6 nativekernel KERNCONF=X86_64_GENERIC` (rc=0; affected .o/.ko produced). No live trigger on this guest (HW/module gated).

PoC changes

Wrote VERDICT.md, fix.diff (one hunk: NULL guard returning -EINVAL), build/run.sh, build.log excerpt, fix_apply.log, env.txt, manifest.json.

Verified recommended fix

Add if (voltage_object == NULL) return -EINVAL; between the lookup (1444-1445) and the first deref at 1447. Supersedes any pre-verification proposal. The full git-apply-able diff lives in findings/poc/DF-1497/fix.diff.

Verdict

ppatomctrl_get_svi2_voltage_object: line 1441-1442 only guards voltage_info (the table) — that pointer is checked. Line 1444-1445 voltage_object = atomctrl_lookup_voltage_type_v3(...) returns NULL at ppatomctrl.c:238 when no voltage object matches (voltage_type, VOLTAGE_OBJ_SVID2). Lines 1447-1449 unconditionally deref voltage_object->asSVID2Obj.ucSVDGpioId/ucSVCGpioId/usLoadLine_PSI → NULL deref → kernel panic. amdgpu powerplay HW-gated as DF-1467. Source-level confirmed.