Windows IOCP poller races unsynchronized registration tables

Reseau 1.0.0 through 1.3.1 access the Windows I/O completion port (IOCP) backend's registration dictionary and zombie vector concurrently from the poller and application threads without consistently taking the same lock. A remote peer can increase the likelihood of the race by driving connection churn and I/O completions at the same time. Linux, macOS, and FreeBSD use different polling backends and are not affected.

Impact

A dictionary rehash or vector mutation that overlaps the poller's unlocked lookup or cleanup can crash or corrupt the poller state. A stale or incorrect lookup can also associate a kernel completion with the wrong I/O operation, potentially causing cross-connection completion misdelivery.

The outcome is probabilistic and timing-dependent; a peer can accelerate the race but does not directly control the conflicting interleaving.

Technical details

Registration and deregistration mutated the IOCP backend's by_ptr dictionary and zombies vector while holding the shared poller-state lock. The dedicated poller thread looked up completions in by_ptr and removed completed registrations from those same non-thread-safe collections without taking that lock. Concurrent insertion could rehash the dictionary while it was being read, and concurrent zombie cleanup could mutate a vector being traversed or searched.

Patches

Upgrade to Reseau 1.3.2 or later. The fixed IOCP dispatch path takes the shared poller-state lock around registration lookup, operation-state transition, and zombie cleanup, matching the synchronization used by the other polling backends.

Workarounds

There is no complete Windows workaround that preserves use of the vulnerable IOCP backend. Running the service on a non-Windows backend avoids the race. Limiting connection churn can reduce its likelihood but does not make concurrent table access safe.

Reported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.