Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Concurrent::ReadWriteLock#releasewritelock 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#releasereadlock 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. It should not be framed as an authorization bypass; the lock is an in-process concurrency primitive, not an access-control boundary. Version Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab Details releasewritelock checks only whether the global counter indicates that a writer is running. It does not track or…
Recommended action: Upgrade to 1.3.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 WRITELOCKHELD. After 32,768 reentrant read acquisitions, the local read count crosses into the write-lock bit. trywritelock then treats the thread as already holding a write lock and returns true without setting the global RUNNINGWRITER 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: When a thread already holds a lock, acquirereadlock increments @HeldCount: After…
Recommended action: Upgrade to 1.3.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 compareandset(oldvalue, newvalue) succeeds. - Numeric compareandset, which checks old == oldvalue before attempting the underlying atomic swap. - 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. Version Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab Details AtomicReference#update retries until compareandset returns true: For numeric expected values, compareandset uses numeric equality before attempting the underlying atomic compare-and-set:…
Recommended action: Upgrade to 1.3.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.