CVE-2026-54905: 
Ruby Analisi e mitigazione delle vulnerabilità

CVE-2026-54905 is a wrap-around error in the Concurrent::ReentrantReadWriteLock class of the concurrent-ruby gem that allows a thread to be incorrectly granted a write lock without mutual exclusivity. The vulnerability affects concurrent-ruby versions prior to 1.3.7 (confirmed on version 1.3.6, commit 7a1b789). It was discovered by Pranjali Thakur (depthfirst.com), published to the GitHub Advisory Database on June 19, 2026, and a patch was released the same day. It carries a CVSS v4.0 base score of 2.0 (Low) (GitHub Advisory, GHSA).

The root cause is a wrap-around error (CWE-128) in the per-thread @HeldCount integer used by ReentrantReadWriteLock to track reentrant lock acquisitions. The low 15 bits store the read hold count, and bit 15 (WRITE_LOCK_HELD = 1 << 15 = 32768) is reserved to indicate a held write lock. When a single thread calls acquire_read_lock exactly 32,768 times, the read count overflows into bit 15, making @HeldCount.value equal to WRITE_LOCK_HELD. Subsequently, try_write_lock checks held >= WRITE_LOCK_HELD and, finding this condition true, takes the fast "already hold write lock" path — returning true and incrementing @HeldCount without ever setting the global RUNNING_WRITER bit in @Counter. Because RUNNING_WRITER is never set, other threads do not observe an active writer and can freely acquire read locks concurrently, breaking the mutual-exclusion guarantee. A public proof-of-concept demonstrating full reproduction is included in the advisory (GitHub Advisory).

Successful triggering of this bug breaks the write-lock exclusivity guarantee of ReentrantReadWriteLock: a thread believes it holds an exclusive write lock while other threads can simultaneously hold or acquire read locks, creating a race condition on any mutable state protected by the lock. This can lead to inconsistent reads, data corruption, or undefined behavior in multi-threaded Ruby applications that rely on this primitive for thread safety. The confidentiality, integrity, and availability of data managed within the lock's critical section are all potentially affected at a low level, though impact is confined to the vulnerable process and does not propagate to subsequent systems (GitHub Advisory, GHSA).

1. Identify target: Locate a Ruby application using concurrent-ruby < 1.3.7 that employs Concurrent::ReentrantReadWriteLock to protect shared mutable state, and where a single thread can perform a high number of reentrant read lock acquisitions (e.g., within a loop).
2. Trigger read-count overflow: From within the target thread, call lock.acquire_read_lock exactly 32,768 times (WRITE_LOCK_HELD times) in a reentrant context. This causes the per-thread @HeldCount value to equal 32768, which is the same bit pattern as WRITE_LOCK_HELD.
3. Invoke try_write_lock: Call lock.try_write_lock. Because @HeldCount.value >= WRITE_LOCK_HELD, the method takes the "already hold write lock" fast path, returns true, and increments @HeldCount by WRITE_LOCK_HELD — without setting the global RUNNING_WRITER bit in @Counter.
4. Exploit the race: While the calling thread believes it holds an exclusive write lock, other threads can still call lock.acquire_read_lock and succeed, since RUNNING_WRITER is not set. Both the "writer" and concurrent readers now access the protected resource simultaneously.
5. Achieve objective: Read or modify shared mutable state concurrently with other threads, causing data races, inconsistent reads, or corruption of the protected resource (GitHub Advisory).

Upgrade concurrent-ruby to version 1.3.7 or later, which contains the fix for this wrap-around error. No configuration-based workaround is available; the only remediation is to update the gem. Applications using Concurrent::ReentrantReadWriteLock in long-running loops with high reentrant read acquisition counts should be treated as highest priority for patching (GitHub Advisory, GHSA).

The advisory was published by eregon (a concurrent-ruby maintainer) on June 16, 2026, and added to the GitHub Advisory Database on June 19, 2026, indicating prompt vendor response. Credit for discovery was given to Pranjali Thakur of depthfirst.com. No significant broader media coverage or notable community commentary beyond the official advisory has been identified at this time (GHSA).