Skip to content
Fencer Intel
no cvss —

JLSEC-2026-803 json

Windows IOCP poller races unsynchronized registration tables

published 3mo ago modified 3mo ago

cvss
—
not scored
cisa kev
Not listed
not in CISA's catalog
epss
—
no score, EPSS covers CVEs only
public exploits
0
none known

Summary

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.

Patch / fix

Is JLSEC-2026-803 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Affected packages

ecosystem package affected fixed in
julia Reseau
>=1.0.0, <1.3.2
1.3.2

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.