โฌข DragonFlyBSD Kernel Audit
DF-4001 / run.log
โ† back to finding โ†“ download raw
BUILD-OK
fiji_smumgr.c demonstrator โ€” kernel struct geometry (kernel headers):
  sizeof(SMU73_Discrete_DpmTable)=1632  GraphicsLevel@+236 MemoryLevel@+612 Sclk_voltageOffset@+1576
  GraphicsLevel=44B MemoryLevel=24B Uvd=16B Ext=12B ArbEntry=12B ArbTable(stack)=384B

=== DF-4001a fiji_populate_all_graphic_levels -> GraphicsLevel[8] (heap, inside struct fiji_smumgr) ===
  sclk_count=12: 4 OOB level writes, 176 bytes past GraphicsLevel[8]
  redzone dirty bytes observed: 176
  levels[sclk_count-1].DisplayWatermark store at :1042 also OOB (count-1=11 > 7)
  with ucNumEntries=255: 10868 bytes past the array; DpmTable tail after GraphicsLevel is ~1044B -> blows past smc_state_table and the whole fiji_smumgr kzalloc

=== DF-4001b fiji_populate_all_memory_levels -> MemoryLevel[4] (heap) ===
  mclk_count=6 (Fiji SMU73 bound is 4!): 2 OOB writes, 48 bytes past MemoryLevel[4]
  redzone dirty bytes observed: 48

=== DF-4001c fiji_program_memory_timing_parameters -> SMU73_Discrete_MCArbDramTimingTable arb_regs (384B STACK object) ===
  sclk=12 mclk=6: 72 entry writes total, 26 PAST the 32-entry table (max linear entry 49 of 32)
  deepest write offset 600B into a 384B stack object -> 216 bytes into the caller frame (216 frame bytes actually smashed here)
  with ucNumEntries=255/255 the walk reaches offset 15300B past the 384B object (kernel stack smash, return-address direction)
  (the earlier version of this demo smashed its OWN stack frame and died of SIGBUS โ€” that bus error was the bug demonstrating itself)

=== DF-4002 fiji_populate_smc_{vce,acp,uvd}_level -> VceLevel[8]/AcpLevel[8]/UvdLevel[8] (heap) ===
  VceLevel[8]:  mm_count=20 -> 12 OOB writes, 144 bytes past
  AcpLevel[8]:  mm_count=20 -> 12 OOB writes, 144 bytes past
  UvdLevel[8]:  mm_count=20 -> 12 OOB writes, 192 bytes past
  (followed in-struct by VceLevel/AcpLevel/SamuLevel/Ulv/Smio[32]; count 255 runs ~3KB past, beyond the fiji_smumgr allocation)

=== DF-4003 fiji_populate_cac_table -> BapmVddcVidLoSidd/HiSidd[16] write + vddc_voltage_table.entries[32] read ===
  vddc_lookup_count=40: 24 OOB writes past BapmVddcVidLoSidd[16] (and same for HiSidd), 8 OOB reads of vddc_voltage_table.entries[32]
  count comes from get_vddc_lookup_table ->count = ucNumEntries (u8<=255) [process_pptables_v1_0.c:176]; with 255: 239B past each array, 223 reads past entries[32]

=== DF-4004 fiji_populate_clock_stretcher_data_table -> Sclk_voltageOffset[8] ===
  dep_sclk->count=12 (RAW count, not the dedup'd dpm count): writes at [8..11] are OOB
  array sits at DpmTable+1576 of 1632B, followed by ClockStretcherDataTable/CKS_LOOKUPTable (struct tail); count 255 writes 247B past the array, off the end of smc_state_table
  note: the walk (:1706) runs BEFORE the stretch_amount validation at :1731, so even a 'rejected' VBIOS value smears the table first

=== DF-4005 fiji_get_dependency_volt_by_clk fall-through reads dep_table->entries[i].mvdd with i == count ===
  count=3, i=3 after fall-through; entries[i].mvdd reads bytes at +60, 12 bytes past the 3-entry heap object
  value read = 0x0001 (nonzero -> *mvdd set from entries[i-1] (in-bounds); zero -> *mvdd left unset) โ€” kernel heap adjacent-slab bytes consumed as a branch condition

=== DF-4006 fiji_populate_smc_vce_level with usMMDependencyTableOffset==0 -> mm_dep_table NULL -> mm_table->count deref ===
  mm_dep_table==NULL when PowerPlay table has usMMDependencyTableOffset==0 (parser keeps result=0 and continues)
  fiji_init_smc_table -> fiji_populate_smc_vce_level:1433 'table->VceLevelCount = (uint8_t)(mm_table->count)'
  child took signal 11 on mm_table->count โ€” in-kernel equivalent: page fault on NULL+offset during fiji_init_smc_table (driver attach / resume) => panic

DEMONSTRATOR COMPLETE: all walks reproduced; counts are single VBIOS bytes (ucNumEntries) reaching the fixed SMC arrays unclamped.
exit=0