# DF-4983 — cxm(4) iic glue: detach-time `CXM_IVAR_IICBUS` invalidation is a permanent no-op → stale `sc->iicbus` device pointer

## What

`cxm_iic_detach()` (sys/dev/video/cxm/cxm_i2c.c:229) tries to clear the
parent's iicbus pointer with `BUS_WRITE_IVAR(..., CXM_IVAR_IICBUS, 0)`
and ignores the return value. The parent's handler
(sys/dev/video/cxm/cxm.c:2115-2118) rejects the write with `EINVAL`
whenever `sc->iicbus` is already set — which it always is at detach
time (the same ivar, written by `cxm_iic_attach()`, is the only setter).
The clear therefore **can never succeed**; `struct cxm_softc.iicbus`
keeps pointing at the iicbus `device_t` after `device_delete_child()`
destroys it.

## Trigger (requires a Conexant iTVC15/16 card)

```
user$:  while :; do ioctl sensor path on /dev/cxm0; done   # any I2C-touching ioctl
root#:  kldunload cxm                                       # cxm_detach → cxm_iic_detach (no-op clear)
        # → in-flight iicbus_start()/iicbus_write() on the freed device_t
```

See `df4983_cxm_iic_stale_ivar.c` for the annotated trace.

## Status on the reference guest

**Not runnable — no cxm hardware.** `cxm.ko`/`cxm_iic.ko` are resident in
`X86_64_GENERIC`, but no Conexant card exists on the QEMU PCI bus, so
`cxm` never attaches and `/dev/cxm*` is never created (env evidence in
DF-4982's env.txt, same session). The defect itself is certain from
source: the reject-when-set guard plus the ignored return leave exactly
one possible outcome (stale pointer) every time cxm_iic_detach runs.

## Relation to known findings

The racy *dereference* window is the already-filed cxm detach-vs-ioctl
family (DF-4753 / DF-4419 twin) — NOT re-reported here. This finding is
the glue-layer defect that makes the second object (iicbus device_t)
un-invalidate-able: the intended lifetime hook is dead code.

## Fix

`fix.diff` — `cxm_write_ivar`: `val == 0` clears unconditionally
(detach mode); non-zero keeps the set-once `EINVAL` guard.