# DF-3163 VERDICT — reproduced (ioctl returns wrong data; functional bug)

## Reproduced?  Yes.
Stock INVARIANTS guest kernel #0 (2026-09-07), unprivileged user: 5 bytes
queued in the fifo; `FIONREAD` on the O_RDONLY fd correctly returns 5,
on the O_RDWR fd returns **0** (run.log).

## Why (line-level)
- fifo_vnops.c:442-450 — FREAD pass: `soo_ioctl(readsock, FIONREAD, data)`
  stores `rso->so_rcv.ssb_cc` (= 5).
- fifo_vnops.c:451-459 — FWRITE pass runs next for an O_RDWR fd:
  `soo_ioctl(writesock, FIONREAD, data)` overwrites the answer with
  `wso->so_rcv.ssb_cc` (= 0; the write socket never receives — data
  flows wso->so_snd <-> rso->so_rcv via unp_connect2, fifo_vnops.c:210).
- sys/kern/sys_socket.c:152-155 — soo_ioctl's FIONREAD case.

## Impact
Any application using FIONREAD on an O_RDWR fifo descriptor (a legal and
common pattern for bidirectional fifo protocols) is told the queue is
always empty — busy-poll loops spin, protocol state machines stall.
Information-correctness bug only; no memory safety impact.  Same quirk
exists in FreeBSD's fifo code, but that does not make it correct.

## Fix validation
`fix.diff`: skip the FWRITE pass for FIONREAD.  On the rebuilt guest
kernel (same build cycle as DF-3161/3162 validation) the PoC reports
`FIONREAD on O_RDWR fd = 5` (see fix_run.log); O_RDONLY control
unchanged.

## Chain summary
Unpriv user -> wrong ioctl answer.  No escalation path.

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.