Skip to content

Commit 55442c5

Browse files
jasnowRubySec CI
authored andcommitted
Updated advisory posts against rubysec/ruby-advisory-db@a25814f
1 parent 7810f48 commit 55442c5

3 files changed

Lines changed: 183 additions & 0 deletions

File tree

Lines changed: 62 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,62 @@
1+
---
2+
layout: advisory
3+
title: 'CVE-2026-54904 (concurrent-ruby): Concurrent Ruby - `AtomicReference#update`
4+
livelocks when the stored value is `Float::NAN`'
5+
comments: false
6+
categories:
7+
- concurrent-ruby
8+
advisory:
9+
gem: concurrent-ruby
10+
cve: 2026-54904
11+
ghsa: h8w8-99g7-qmvj
12+
url: https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54904
13+
title: Concurrent Ruby - `AtomicReference#update` livelocks when the stored value
14+
is `Float::NAN`
15+
date: 2026-06-19
16+
description: |-
17+
### Summary
18+
19+
`Concurrent::AtomicReference#update` can enter a permanent busy retry
20+
loop when the current value is `Float::NAN`.
21+
22+
The issue is caused by the interaction between:
23+
- `AtomicReference#update`, which retries until `compare_and_set(old_value,
24+
new_value)` succeeds.
25+
- Numeric `compare_and_set`, which checks `old == old_value` before
26+
attempting the underlying atomic swap.
27+
- Ruby NaN semantics, where `Float::NAN == Float::NAN` is always `false`.
28+
29+
As a result, once an `AtomicReference` contains `Float::NAN`, calling
30+
`#update` repeatedly evaluates the caller's block and never returns.
31+
In services that store externally derived numeric values in an
32+
`AtomicReference`, this can cause CPU exhaustion or permanent
33+
request/job hangs.
34+
35+
### Impact
36+
37+
This is an application-level denial of service issue. If an application
38+
stores externally derived numeric data in a `Concurrent::AtomicReference`,
39+
an attacker or faulty upstream data source may be able to cause the
40+
stored value to become `Float::NAN`. Any later call to
41+
`AtomicReference#update` on that reference will spin indefinitely,
42+
repeatedly executing the update block and consuming CPU.
43+
44+
### Credit
45+
46+
Pranjali Thakur - depthfirst ([depthfirst.com](<http://depthfirst.com>))
47+
cvss_v4: 8.2
48+
patched_versions:
49+
- ">= 1.3.7"
50+
related:
51+
url:
52+
- https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54904
53+
- https://rubygems.org/gems/concurrent-ruby/versions/1.3.7
54+
- https://github.com/ruby-concurrency/concurrent-ruby/releases/tag/v1.3.7
55+
- https://advisories.gitlab.com/gem/concurrent-ruby/CVE-2026-54904
56+
- https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-h8w8-99g7-qmvj
57+
- https://github.com/advisories/GHSA-h8w8-99g7-qmvj
58+
notes: |
59+
- cvss_v4 from GHSA
60+
- CVE is reserved, but not published.
61+
- Not on nvd.nist.gov so no cvss_v2 or cvss_v3.
62+
---
Lines changed: 58 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,58 @@
1+
---
2+
layout: advisory
3+
title: 'CVE-2026-54905 (concurrent-ruby): Concurrent Ruby - `ReentrantReadWriteLock`
4+
read-count overflow grants a write lock without exclusivity'
5+
comments: false
6+
categories:
7+
- concurrent-ruby
8+
advisory:
9+
gem: concurrent-ruby
10+
cve: 2026-54905
11+
ghsa: wv3x-4vxv-whpp
12+
url: https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54905
13+
title: Concurrent Ruby - `ReentrantReadWriteLock` read-count overflow grants a write
14+
lock without exclusivity
15+
date: 2026-06-19
16+
description: |-
17+
### Summary
18+
19+
`Concurrent::ReentrantReadWriteLock` can incorrectly grant a write lock
20+
after one thread acquires the read lock 32,768 times.
21+
22+
The lock stores a thread's local read and write hold counts in one
23+
integer. The low 15 bits are used for the read hold count, and bit 15
24+
is used as `WRITE_LOCK_HELD`. After 32,768 reentrant read acquisitions,
25+
the local read count crosses into the write-lock bit. `try_write_lock`
26+
then treats the thread as already holding a write lock and returns
27+
`true` without setting the global `RUNNING_WRITER` bit.
28+
29+
This breaks the core mutual-exclusion guarantee: the caller is told
30+
it has a write lock, but other threads can still hold or acquire
31+
read locks at the same time.
32+
33+
### Impact
34+
35+
This breaks the write-lock exclusivity guarantee. After the overflow,
36+
a thread can be told it has acquired the write lock while other threads
37+
can still hold or acquire read locks, allowing races and inconsistent
38+
reads of protected mutable state.
39+
40+
### Credit
41+
42+
Pranjali Thakur - depthfirst ([depthfirst.com](<http://depthfirst.com>))
43+
cvss_v4: 2.0
44+
patched_versions:
45+
- ">= 1.3.7"
46+
related:
47+
url:
48+
- https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54905
49+
- https://rubygems.org/gems/concurrent-ruby/versions/1.3.7
50+
- https://github.com/ruby-concurrency/concurrent-ruby/releases/tag/v1.3.7
51+
- https://advisories.gitlab.com/gem/concurrent-ruby/CVE-2026-54905
52+
- https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-wv3x-4vxv-whpp
53+
- https://github.com/advisories/GHSA-wv3x-4vxv-whpp
54+
notes: |
55+
- cvss_v4 from GHSA
56+
- CVE is reserved, but not published.
57+
- Not on nvd.nist.gov so no cvss_v2 or cvss_v3.
58+
---
Lines changed: 63 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,63 @@
1+
---
2+
layout: advisory
3+
title: 'CVE-2026-54906 (concurrent-ruby): Concurrent Ruby - ReadWriteLock allows wrong-thread
4+
write release and stray read-release counter corruption'
5+
comments: false
6+
categories:
7+
- concurrent-ruby
8+
advisory:
9+
gem: concurrent-ruby
10+
cve: 2026-54906
11+
ghsa: 6wx8-w4f5-wwcr
12+
url: https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54906
13+
title: Concurrent Ruby - ReadWriteLock allows wrong-thread write release and stray
14+
read-release counter corruption
15+
date: 2026-06-19
16+
description: |-
17+
### Summary
18+
19+
`Concurrent::ReadWriteLock#release_write_lock` does not verify that the
20+
calling thread acquired the write lock. Any thread with access to the
21+
lock object can release an active write lock held by another thread. A
22+
second writer can then enter its critical section while the first writer
23+
is still running.
24+
25+
`Concurrent::ReadWriteLock#release_read_lock` also decrements the shared
26+
counter even when no read lock is held. Calling it on a fresh lock
27+
changes the counter from `0` to `-1`, after which normal read acquisition
28+
raises `Concurrent::ResourceLimitError`.
29+
30+
This is a synchronization correctness issue in the public
31+
`Concurrent::ReadWriteLock` API. It should not be framed as an
32+
authorization bypass; the lock is an in-process concurrency primitive,
33+
not an access-control boundary.
34+
35+
### Impact
36+
37+
This can break the write-lock mutual exclusion guarantee and can also
38+
leave a lock unusable after a stray read release.
39+
The impact is local to applications that expose or misuse the manual
40+
`acquire_*` / `release_*` APIs. If the lock protects integrity-sensitive
41+
mutable state, wrong-thread write release can allow concurrent writers
42+
and data races. The stray read-release path can cause denial of service
43+
by corrupting the lock counter.
44+
45+
### Credit
46+
47+
Pranjali Thakur - depthfirst ([depthfirst.com](<http://depthfirst.com>))
48+
cvss_v4: 2.1
49+
patched_versions:
50+
- ">= 1.3.7"
51+
related:
52+
url:
53+
- https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54906
54+
- https://rubygems.org/gems/concurrent-ruby/versions/1.3.7
55+
- https://github.com/ruby-concurrency/concurrent-ruby/releases/tag/v1.3.7
56+
- https://advisories.gitlab.com/gem/concurrent-ruby/CVE-2026-54906
57+
- https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-6wx8-w4f5-wwcr
58+
- https://github.com/advisories/GHSA-6wx8-w4f5-wwcr
59+
notes: |
60+
- cvss_v4 from GHSA
61+
- CVE is reserved, but not published.
62+
- Not on nvd.nist.gov so no cvss_v2 or cvss_v3.
63+
---

0 commit comments

Comments
 (0)