# DF-5052 — dal_vector_destruct() leaves `container` dangling → double kfree (runtime-demonstrated)

`sys/dev/drm/amd/display/dc/basics/vector.c:131-137`.

## Build / Run / Expected

Same `/dev/kmem` call facility as DF-5051 (see ../DF-5051/README.md and kv.c).

```sh
cc -O2 -o /root/kv kv.c
kldload amdgpu
V=$(/root/kv call <base+11d070> 0 4 10)    # dal_vector_create(NULL,4,16)
/root/kv call <base+11d120> $V             # dal_vector_destruct  #1 (frees container)
KV_BCOPY=<bcopy> /root/kv kread $V 32      # container STILL set (dangling), count/capacity 0
/root/kv call <base+11d120> $V             # dal_vector_destruct  #2 -> kfree(dangling)
# EXPECTED (unfixed): panic "memory chunk 0x... is already free!" with trace
#   chunk_mark_free() -> _kfree() -> dal_vector_destruct() -> (trampoline) -> syscall2
```

Fix-semantics check (run-fixcheck.sh): after destruct #1, write NULL over
`vector->container` (exactly the state change fix.diff makes the function
perform itself), then destruct #2 must return cleanly (kfree(NULL) is a no-op
via the kfree macro's NULL guard, sys/dev/drm/include/linux/slab.h:36-39) and
two subsequent 64-byte allocations must return distinct pointers.

## Results

Baseline: REPRODUCED — `panic: memory chunk 0xfffff80116c07ac0 is already
free!` attributed to `dal_vector_destruct+0x20` (panic-baseline-doublefree.log).

Fix semantics: CONFIRMED — with `container=NULL` injected between the calls,
destruct #2 returned without any panic and the re-allocations were distinct
(fix-semantics-validation.log).