⬢ DragonFlyBSD Kernel Audit
DF-4778 / verdict.json
← back to finding ↓ download raw 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
{
  "finding_id": "DF-4778",
  "status": "untested",
  "reproduced": 0,
  "impact": "none",
  "confidence": "certain",
  "verdict": "Runtime-untested: requires an AMD DCE80-DCE120 DisplayPort AUX engine and a partially-ACKing DP sink, neither present on the audit QEMU guest. Code defect confirmed by line-level trace: process_read_request() points ctx->reply.data at ctx->buffer instead of ctx->buffer + ctx->offset (aux_engine.c:204-205), so every continuation chunk of a partial-ACK native/I2C-AUX read overwrites the start of the caller buffer instead of appending at offset. Copy remains in bounds (aux_engine.c:196 bound + offset invariant), so impact is corrupted DPCD/EDID read data (display link misconfiguration), not kernel memory unsafety. Identical line in the twin engine dce/dce_aux.c:502.",
  "exploit_chain": "",
  "evidence": "VERDICT.md (line-level trace + bound-safety argument + reachability); fix.diff (offset fix in both engines)",
  "kernel_refs": [
    "sys/dev/drm/amd/display/dc/i2caux/aux_engine.c:132",
    "sys/dev/drm/amd/display/dc/i2caux/aux_engine.c:196",
    "sys/dev/drm/amd/display/dc/i2caux/aux_engine.c:204",
    "sys/dev/drm/amd/display/dc/i2caux/aux_engine.c:284",
    "sys/dev/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c:281",
    "sys/dev/drm/amd/display/dc/dce/dce_aux.c:502"
  ],
  "poc_changes": "n/a (source-level finding; no runnable PoC on this guest)",
  "attempts": 0,
  "guest_uname": "DragonFly dfbsd 6.5-DEVELOPMENT #0: Thu Jul  2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 (no AMD GPU)",
  "runtime_sec": 0,
  "guest_dirty": 0,
  "build_cmd": "n/a (no HW path on guest)",
  "run_cmd": "n/a (requires AMD DCE DP AUX hardware)",
  "code_hash": "",
  "notes": "Pass-2 new finding, distinct from known DF-1868/DF-1938 (write-reply stack overflow): this is the READ side and the same code region the task list asked to re-examine ((a) process_reply reply-length/buffer handling). In-bounds corruption only; filed Low. Folded into this finding rather than filed separately: the base class also never clamps payload length to the AUX 16-byte maximum before submit_channel_request() (aux_engine.c:287, 503; silent HW length-nibble truncation at aux_engine_dce110.c:253-255) - same base class trusts upper layer root cause, no kernel memory-safety consequence beyond DF-1868.",
  "recommended_fix": "ctx->reply.data = ctx->buffer + ctx->offset; in i2caux/aux_engine.c and dce/dce_aux.c (see fix.diff)",
  "fix_status": "not_testable",
  "fix_baseline_reproduced": 0,
  "fix_patched_reproduced": 0,
  "fix_verdict": "fix.diff applies to both engines; cannot boot-test on a guest without AMD hardware",
  "fix_evidence": "fix.diff (2 hunks, aux_engine.c:205 + dce_aux.c:502)"
}