Concurrent Ruby - `ReentrantReadWriteLock` read-count overflow grants a write lock without exclusivity
Published: June 19, 2026
SECURITY IDENTIFIERS
- CVE: CVE-2026-54905 (NVD)
- GHSA: GHSA-wv3x-4vxv-whpp
GEM
PATCHED VERSIONS
>= 1.3.7
DESCRIPTION
Summary
Concurrent::ReentrantReadWriteLock can incorrectly grant a write lock
after one thread acquires the read lock 32,768 times.
The lock stores a thread's local read and write hold counts in one
integer. The low 15 bits are used for the read hold count, and bit 15
is used as WRITE_LOCK_HELD. After 32,768 reentrant read acquisitions,
the local read count crosses into the write-lock bit. try_write_lock
then treats the thread as already holding a write lock and returns
true without setting the global RUNNING_WRITER bit.
This breaks the core mutual-exclusion guarantee: the caller is told it has a write lock, but other threads can still hold or acquire read locks at the same time.
Impact
This breaks the write-lock exclusivity guarantee. After the overflow, a thread can be told it has acquired the write lock while other threads can still hold or acquire read locks, allowing races and inconsistent reads of protected mutable state.
Credit
Pranjali Thakur - depthfirst (depthfirst.com)
RELATED
- https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54905
- https://rubygems.org/gems/concurrent-ruby/versions/1.3.7
- https://github.com/ruby-concurrency/concurrent-ruby/releases/tag/v1.3.7
- https://advisories.gitlab.com/gem/concurrent-ruby/CVE-2026-54905
- https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-wv3x-4vxv-whpp
- https://github.com/advisories/GHSA-wv3x-4vxv-whpp
