Approved changes feed: RSS · Atom

cpe:2.3:a:ruby-concurrency:concurrent-ruby:*:*:*:*:*:*:*:*

part: a version: * update: *

VendorRuby Concurrency (d546489b-ab33-5912-b5ed-fa8b5be49216)
ProductConcurrent Ruby (26f659cd-015e-54b4-90fa-fd2cf17ad993)
Edition*
Language*
Software edition*
Target software*
Target hardware*
Other*

Notes

Imported from gcve-enriched-dumps CVE data

PURL mappings

PURLSourceLast updated
No PURL mappings for this CPE yet.

Vulnerability references

IdentifiercpeApplicabilitySubmitteddb.gcve.eu detailsRationale
CVE:CVE-2026-54906 vulnerable 2026-07-29 01:00:28.103805 concurrent-ruby: ReadWriteLock allows wrong-thread write release and stray read-release counter corruption
concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, Concurrent::ReadWriteLock#release_write_lock does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running. Concurrent::ReadWriteLock#release_read_lock also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from 0 to -1, after which normal read acquisition raises Concurrent::ResourceLimitError. This is a synchronization correctness issue in the public Concurrent::ReadWriteLock API. This vulnerability is fixed in 1.3.7.
Published: 2026-06-24T15:46:01.116Z
Updated: 2026-06-24T17:57:07.650Z
Reference links
Imported from gcve-enriched-dumps CVE data
CVE:CVE-2026-54905 vulnerable 2026-07-29 01:00:28.103663 concurrent-ruby: `ReentrantReadWriteLock` read-count overflow grants a write lock without exclusivity
concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, 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. This vulnerability is fixed in 1.3.7.
Published: 2026-06-24T15:42:44.257Z
Updated: 2026-06-24T16:41:34.224Z
Reference links
Imported from gcve-enriched-dumps CVE data
CVE:CVE-2026-54904 vulnerable 2026-07-29 01:00:28.103380 concurrent-ruby: `AtomicReference#update` livelocks when the stored value is `Float::NAN`
concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, Concurrent::AtomicReference#update can enter a permanent busy retry loop when the current value is Float::NAN. The issue is caused by the interaction between AtomicReference#update, which retries until compare_and_set(old_value, new_value) succeeds; Numeric compare_and_set, which checks old == old_value before attempting the underlying atomic swap.; and Ruby NaN semantics, where Float::NAN == Float::NAN is always false. As a result, once an AtomicReference contains Float::NAN, calling #update repeatedly evaluates the caller's block and never returns. In services that store externally derived numeric values in an AtomicReference, this can cause CPU exhaustion or permanent request/job hangs. This vulnerability is fixed in 1.3.7.
Published: 2026-06-24T15:44:21.992Z
Updated: 2026-08-05T17:36:28.452Z
Reference links
Imported from gcve-enriched-dumps CVE data

Contribute

You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.

Inspect record JSON

Open JSON directly

Open this panel to browse, search, copy or download the JSON record.