# DF-3467 - VERDICT

**status: not_reproduced | reproduced: 0 | impact: none | confidence: likely**

Attempted and not reproduced. The vulnerable code path was exercised at full rate: ipfw3+ipfw3_basic+ipfw3_layer4 loaded on the stock guest, rule '100 allow udp from any to any uid 1001' active, and six unprivileged (uid 1001) threads raced 3,599,984 UDP socket()/connect()/send()/close() cycles against 10.0.2.2 so the output-direction check_uid ran in the sender threads (ipfw3 counter 00100 = 3,599,984 packets / 331,198,528 bytes matched by the uid rule) while concurrent close(2) storms tore the pcbs down. Zero panics, zero anomalies across all runs; guest healthy after. The UAF window between in_pcblookup_hash() (ip_fw3_layer4.c:120/125, no pcbinfo token held) and the inp_socket deref (:130/:136/:139) is a handful of instructions against the detaching CPUs hash-removal - the finding remains code-plausible (lookup takes no reference and no token; the wildcard path in the same file shows the intended token discipline) but did not manifest in 3.6M matched packets under a close storm. Read-only UAF ceiling (panic at most) unchanged.

## Kernel references
- sys/net/ipfw3_layer4/ip_fw3_layer4.c:120
- sys/net/ipfw3_layer4/ip_fw3_layer4.c:130
- sys/net/ipfw3_layer4/ip_fw3_layer4.c:136

## Evidence
run.log (full ipfw3 show counters + RACEUID-DONE lines), raceuid.c

## Recommended fix
hold the per-CPU pcbinfo token across lookup+dereference in ip_fw3_match_guid (as the wildcard path does), or take a pcb reference.

## 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.