listenContext.performHandshake, in its failure branch, zeroes ep.h and
releases ep.mu before calling ep.Close(); the endpoint state only changes
later, inside closeLocked. In that window the endpoint is still
SynSent/SynRecv, so connecting() is true.
A segment arriving there wakes the dispatcher, which routes to
handleConnecting. Its gate checks the state but not h, so
ep.h.processSegments() runs on a nil handshake and panics with a nil
receiver at connect.go:534 — killing the whole process, not just the
connection. The two conditions used to coincide; they stopped coinciding
once zeroing h moved ahead of Close().
Fix: bail out early when ep.h is nil, releasing the mutex the same way the
existing state gate does. One guard covers all five ep.h dereferences in
handleConnecting (processSegments, listenEP in the error branch, and both
inside deliverAccepted, which is only reached from here).
Trigger in the field: TCP that never reaches established (silent server,
RST, timeout) while SYN retransmits keep arriving. Reproduced from a
device crash bundle (sing-box 1.14.0-lx.19-rc.3, android/arm64) where both
sides of the race hold the same endpoint address; the accompanying test
recreates that window and panics without this guard.
SPECS/TASKS/048-GVISOR_HANDSHAKE_NIL_CRASH
ffebe42860