# DF-0664 — VERDICT

## Verdict: NOT REPRODUCED on this kernel — cited file is DEAD CODE (not built)

The missing-locking / TOCTOU / UAF claims against
`sys/netgraph/ng_device.c` are **real at the source level** (the file
does use a global softc + SLIST with no mutex; the cdevsw entry points
do unlocked `SLIST_FOREACH`; `rcvdata`/`disconnect` mutate the list
concurrently with readers — verbatim from the cited lines). **However**,
the cited file is **not built by any standard kernel configuration or
loadable module on DragonFly master**:

```
$ grep "ng_device" sys/conf/files
netgraph7/ng_device.c		optional netgraph7_device
```

Only the rewritten `sys/netgraph7/ng_device.c` is registered (under
`optional netgraph7_device`); it uses `priv_p` / IF queues with proper
locking and has none of the cited bugs. The OLD `sys/netgraph/ng_device.c`
is retained as historical dead code and is **never compiled**.

Verified on the running guest (#0 build, `6.5-DEVELOPMENT`):
- `nm /boot/kernel/kernel | grep ngdwrite` → no matches
- `ls /boot/kernel/ | grep ng_device` → no matches
- `kldstat` → no ng_device module loaded; none exists at `/boot/kernel/`

This is the same dead-code situation already established for DF-0663
(SLIST_REMOVE-on-never-inserted-element), which was verified against
the same file with the same conclusion.

## Mechanism (cited line-by-line; would be real if compiled)

- `sys/netgraph/ng_device.c:336` `ngd_softc sc` — single global softc.
- `:345` `SLIST_FOREACH(tmp, &sc->head, links)` in `ng_device_rcvdata` — no lock.
- `:371-373` reads/writes `connection->loc` and memcpy into `readq` —
  concurrent with `ngdwrite`/`ngdread` which also touch `loc` and `readq`.
- `:396-411` `ng_device_disconnect` frees `readq` and `SLIST_REMOVE`s
  with no synchronization against in-flight readers.
- `:518`, `:572`, `:617` — `ngdread`/`ngdwrite`/`ngdpoll` all do the same
  unlocked `SLIST_FOREACH` lookup of `dev->connection`.
- No `lockmgr(9)`, `crit_enter()`, `spinlock`, or refcount is taken on
  the `connection` object anywhere in the file.

If this file were compiled in, concurrent `read()`/`disconnect()` (or
`rcvdata`/`ngdread`) racing on the same hook could UAF the `readq`
buffer or underflow `connection->loc` → corruption/panic.

## Why the live kernel cannot trigger this

The file is **not registered** in `sys/conf/files`. To make it live, an
administrator would have to manually add a line such as
`netgraph/ng_device.c optional netgraph_device` and rebuild the kernel
— something no DragonFly release has shipped in many years (netgraph7
superseded netgraph v0). The active `netgraph7/ng_device.c` rewrite
uses `priv_p` and per-connection locks.

## Privilege / threat model

- Latent dead-code bug, not exploitable on stock DragonFly.
- The realistic recommendation is to **delete the dead file**
  (`sys/netgraph/ng_device.c` and its header) to prevent confusion, the
  same recommendation as DF-0663.

## Recommended fix

Delete the dead file (preferred), or if kept for historical reference,
add proper locking + connection refcounts. The bundled `fix.diff`
deletes the file. This **supersedes** the finding's source-level
locking proposal (which would patch a file that is not compiled in).