Описание
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.
A flaw was found in concurrent-ruby, a Ruby library for managing concurrent operations. The Concurrent::ReadWriteLock component contains a synchronization issue where write locks can be released by unauthorized threads. This could allow multiple threads to write concurrently, potentially leading to data corruption. Furthermore, an issue with read lock management can cause a denial of service (DoS) by preventing legitimate read operations.
Отчет
This is essentially a library misuse scenario. The attack requires local code execution in the same Ruby process AND use of the manual locking API (ReadWriteLock). Most applications use Concurrent::Future, Concurrent::Promise, Concurrent::Promises, Concurrent::Array/Hash, and Concurrent::Atom — not the low-level ReadWriteLock.
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. The bug requires an attacker to execute code that has access to the same Concurrent::ReadWriteLock object. It is an in-process API misuse issue, not a remotely reachable vulnerability.
Меры по смягчению последствий
The concurrent-ruby package ships Concurrent::ReadWriteLock, which contains a synchronization flaw allowing concurrent readers and writers under high-contention workloads.
Updating to concurrent-ruby version 1.3.5 or later resolves this issue.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat 3scale API Management Platform 2 | 3scale-amp21/backend | Not affected | ||
| Red Hat 3scale API Management Platform 2 | 3scale-amp21/system | Not affected | ||
| Red Hat 3scale API Management Platform 2 | 3scale-amp21/zync | Not affected | ||
| Red Hat 3scale API Management Platform 2 | 3scale-amp22/backend | Not affected | ||
| Red Hat 3scale API Management Platform 2 | 3scale-amp22/system | Not affected | ||
| Red Hat 3scale API Management Platform 2 | 3scale-amp22/zync | Not affected | ||
| Red Hat 3scale API Management Platform 2 | 3scale-amp26/toolbox | Not affected | ||
| Red Hat 3scale API Management Platform 2 | 3scale-amp2/backend-rhel8 | Not affected | ||
| Red Hat 3scale API Management Platform 2 | 3scale-amp2/system-rhel7 | Not affected | ||
| Red Hat 3scale API Management Platform 2 | 3scale-amp2/system-rhel8 | Not affected |
Показывать по
Дополнительная информация
Статус:
EPSS
3.6 Low
CVSS3
Связанные уязвимости
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.
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.
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 Ruby: ReadWriteLock allows wrong-thread write release and stray read-release counter corruption
EPSS
3.6 Low
CVSS3