# DF-4658 — lpoutput drives hardware & resurrects IFF_RUNNING without IFF_UP/bus ownership

**File:** sys/dev/netif/plip/if_plip.c:602,609 (plus :613-616,685-688,730-733)
**Class:** CWE-1254/incorrect state management — Low severity, certain
**Verdict:** REPRODUCED (mechanism + anomalous flags; dos-flavored)

## Repro (guest, run.log)
1. root: `ifconfig lp0 10.99.0.1 10.99.0.2 up` (plip owns ppbus, intr attached)
2. root: `ifconfig lp0 down` → flags `<POINTOPOINT,SIMPLEX,MULTICAST,PROXY>`
   (no UP, no RUNNING; ppb_release_bus tore down lp_intr — ppbconf.c:514-521)
3. unpriv user sends ONE UDP packet to the still-routed peer:
   `./plipspin 10.99.0.2 1 1400` → lpoutput runs anyway: sets
   IFF_RUNNING (if_plip.c:602), ppb_wctr(IRQENABLE) (:609), transmits,
   and calls lp_intr directly (:730) — **while plip no longer owns the bus**.
   → flags now `<POINTOPOINT,RUNNING,...>`: RUNNING on a DOWN interface.
4. root: `ifconfig lp0 up` → lands in a broken half-state
   (`<UP,POINTOPOINT,...>` w/o RUNNING/setup-path): the UP transition at
   if_plip.c:315 requires !RUNNING; the flag merge vs the RUNNING bit set
   by the stray output makes the setup path skip/mis-order — no bus
   request/intr setup is guaranteed for the resurrected state.

## Impact
Any unprivileged user with a route via lp0 during a down window: (a)
corrupts a concurrent lpt0 job on the same port (writes DTR/CTR), (b)
re-enables port IRQs with no handler attached (stray-IRQ storm
potential), (c) leaves the interface in inconsistent RUNNING states.
On the guest, (c)+flags anomaly demonstrated byte-for-byte in run.log.