PoC DF-1575: process_pptables_v1_0 NULL deref when vdd_dep_on_sclk missing

Class: NULL pointer deref Cited site: sys/dev/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c:794,808-810,816-818,843-845,522,745

Reproduction status

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

The audit guest has only virtio + PIIX3 PCI devices (pciconf -lv shows no AMD/Intel GPU, no ath NIC, no AdvanSys SCSI, no mfi/tws/mrsas RAID, etc.), so the cited code path is not reachable at runtime on this guest.

The bug is confirmed at the source level by tracing the cited path:line in sys/dev/drm/amd/powerplay/hwmgr/process_pptables_v1_0.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

init_clock_voltage_dependency: vdd_dep_on_sclk NULL when usSclkDependencyTableOffset==0 (794). get_pcie_table 522 pcie_count = vdd_dep_on_sclk->count + 1 NO NULL check -> panic. get_gpio_table 745 derefs vdd_dep_on_sclk->count NO NULL check. GPIO table pointer at 790-792 non-NULL even when offset==0 (equals powerplay_table) so gate at 843 never filters.

Realistic impact ceiling (on suitable HW)

deterministic NULL deref panic via crafted VBIOS (root pp_table sysfs or malicious VFIO)

Fix

NULL-guard vdd_dep_on_sclk at the top of get_pcie_table and get_gpio_table; return -EINVAL if absent.

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

How to validate the fix

scp -F dfbsd-qemu/config fix.diff dfbsd:/root/DF-1575.diff
ssh -F dfbsd-qemu/config dfbsd 'cd /usr/src && patch -p1 --forward < /root/DF-1575.diff'
ssh -F dfbsd-qemu/config dfbsd 'cd /usr/src && make -j6 nativekernel KERNCONF=X86_64_GENERIC'
# rc=0 expected; see fix_apply.log + fix_build.log in this folder.

VERDICT — DF-1575: process_pptables_v1_0 NULL deref when vdd_dep_on_sclk missing

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/process_pptables_v1_0.c:794,808-810,816-818,843-845,522,745, but the affected driver attaches only to hardware not present in the audit QEMU guest (only virtio+PIIX3 PCI devices, no AMD/Intel GPUs, no ath NICs, no AdvanSys SCSI, no mfi/tws/mrsas RAID, etc.), so it cannot be live-triggered here. The fix.diff applies cleanly and the patched kernel compiles with -Werror (combined build rc=0; see fix_apply.log).

Mechanism (cited path → primitive → effect)

init_clock_voltage_dependency: vdd_dep_on_sclk NULL when usSclkDependencyTableOffset==0 (794). get_pcie_table 522 pcie_count = vdd_dep_on_sclk->count + 1 NO NULL check -> panic. get_gpio_table 745 derefs vdd_dep_on_sclk->count NO NULL check. GPIO table pointer at 790-792 non-NULL even when offset==0 (equals powerplay_table) so gate at 843 never filters.

Reachability on this guest

No — sys/dev/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c:794 is in a driver/module that only attaches to hardware absent from the audit guest. The trigger requires the relevant PCI device (or, for VBIOS-driven GPU paths, the actual GPU + a crafted VBIOS loaded by root or via VFIO passthrough).

Phase 6 — escalation potential

This is a NULL pointer deref 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).

Realistic impact ceiling on suitable HW: deterministic NULL deref panic via crafted VBIOS (root pp_table sysfs or malicious VFIO).

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 the combined make -j6 nativekernel KERNCONF=X86_64_GENERIC build (kernel build rc=0; see manifest.json).
• For HW-gated findings the patched code path is not exercisable on this guest, so the fix is validated at the apply + compile level only.

Fix approach: NULL-guard vdd_dep_on_sclk at the top of get_pcie_table and get_gpio_table; return -EINVAL if absent.

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.