# DF-4778 — aux_engine.c read-continuation copies reply chunks to buffer BASE, not `buffer + offset`

## Finding
`sys/dev/drm/amd/display/dc/i2caux/aux_engine.c` (base class for the DCE80–DCE120
AUX engines) — `process_read_request()` sets

```c
ctx->reply.length = ctx->returned_byte;
ctx->reply.data   = ctx->buffer;          /* line 204-205: missing "+ ctx->offset" */
```

while the multi-iteration read loop in `read_command()` advances
`ctx->offset += ctx->returned_byte` on every partial ACK
(`process_read_reply()`, aux_engine.c:132-135) and re-points the *request* at
`buffer + offset` (aux_engine.c:284-287). The concrete engine
(`i2caux/dce110/aux_engine_dce110.c:281-331 read_channel_reply`) copies
`reply->length` bytes from the AUX SW data registers **into `reply->data`** —
i.e. into the BASE of the caller buffer on every iteration. Consequences on a
continued (partial-ACK) native DPCD / I2C-over-AUX read:

* iteration 2+ overwrites bytes `[0, returned_byte)` instead of appending at
  `[offset, offset+returned_byte)` — the first chunk's data is destroyed and
  the caller (EDID / DPCD / link-training readers) gets chunk #2 at offset 0,
  chunk #3 at offset 0 again, etc.;
* `request->data` (used by the hardware submit path) and `reply->data` (used
  by the software reply path) disagree — the transaction returns "success"
  with corrupted contents.

The copy stays **in bounds** (`returned_byte ≤ current_read_length` is enforced
at aux_engine.c:196, and `offset + current_read_length` is invariant), so this
is a data-integrity bug in the display-link configuration path, not a memory-
safety bug. The identical line exists in the newer sibling engine
`sys/dev/drm/amd/display/dc/dce/dce_aux.c:502` (shared DAL lineage; Linux
removed the whole `i2caux/` tree in 2018).

## Reproduce
Not runnable on the audit guest: the path requires an AMD GPU (DCE80–DCE120
DisplayPort AUX engine) — the QEMU guest has no AMD graphics device and the
`amdgpu`/DC code is not in the loaded kernel. Reproduction on hardware needs
a DP sink that ACKs a native DPCD read partially (fewer bytes than requested)
and a DPCD read of length > 16 (or any read that takes 2+ iterations), then
comparing the returned bytes with the expected chunk order — chunk N+1 will
appear at offset 0.

## Fix
`fix.diff` (this directory): `ctx->reply.data = ctx->buffer + ctx->offset;` in
both `i2caux/aux_engine.c` and `dce/dce_aux.c`. Compile-validated only (no HW).

## Files
  VERDICT.md     full analysis + why it cannot run on this guest
  fix.diff       git-apply-able unified diff (both engines)
  manifest.json  machine-readable catalog