Bug 2497307 - CVE-2026-54905 rubygem-concurrent-ruby: Concurrent-ruby: Incorrect write lock granting leading to broken mutual exclusion [epel-all]
Summary: CVE-2026-54905 rubygem-concurrent-ruby: Concurrent-ruby: Incorrect write lock...
Keywords:
Status: NEW
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: rubygem-concurrent-ruby
Version: epel10
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
Assignee: Vít Ondruch
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: {"flaws": ["915baf76-af8c-4e31-8e91-4...
Depends On:
Blocks: CVE-2026-54905
TreeView+ depends on / blocked
 
Reported: 2026-07-06 09:25 UTC by Vipul Nair
Modified: 2026-07-06 09:25 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Vipul Nair 2026-07-06 09:25:51 UTC
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

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.


Note You need to log in before you can comment on or make changes to this bug.