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
- julia Reseau 1.3.2
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 FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| julia | Reseau | >=1.0.0, <1.3.2 |
1.3.2 |
References
Sources
- OSV JLSEC-2026-803
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.