Merge pull request #1137 from jasnow/ghsa-syncbot-2026-06-21-12_42_28

GHSA/SYNC: 3 new concurrent-ruby gem advisories

LGTM

Author: jasnow

gems/concurrent-ruby/CVE-2026-54904.yml

@@ -0,0 +1,54 @@
+---
+gem: concurrent-ruby
+cve: 2026-54904
+ghsa: h8w8-99g7-qmvj
+url: https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54904
+title: Concurrent Ruby - `AtomicReference#update` livelocks when the
+  stored value is `Float::NAN`
+date: 2026-06-19
+description: |
+  ### Summary
+
+  `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.
+  - 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.
+
+  ### Impact
+
+  This is an application-level denial of service issue. If an application
+  stores externally derived numeric data in a `Concurrent::AtomicReference`,
+  an attacker or faulty upstream data source may be able to cause the
+  stored value to become `Float::NAN`. Any later call to
+  `AtomicReference#update` on that reference will spin indefinitely,
+  repeatedly executing the update block and consuming CPU.
+
+  ### Credit
+
+  Pranjali Thakur - depthfirst ([depthfirst.com](<http://depthfirst.com>))
+cvss_v4: 8.2
+patched_versions:
+  - ">= 1.3.7"
+related:
+  url:
+    - https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54904
+    - https://rubygems.org/gems/concurrent-ruby/versions/1.3.7
+    - https://github.com/ruby-concurrency/concurrent-ruby/releases/tag/v1.3.7
+    - https://advisories.gitlab.com/gem/concurrent-ruby/CVE-2026-54904
+    - https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-h8w8-99g7-qmvj
+    - https://github.com/advisories/GHSA-h8w8-99g7-qmvj
+notes: |
+  - cvss_v4 from GHSA
+  - CVE is reserved, but not published.
+    - Not on nvd.nist.gov so no cvss_v2 or cvss_v3.

gems/concurrent-ruby/CVE-2026-54905.yml

@@ -0,0 +1,50 @@
+---
+gem: concurrent-ruby
+cve: 2026-54905
+ghsa: wv3x-4vxv-whpp
+url: https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54905
+title: Concurrent Ruby - `ReentrantReadWriteLock` read-count overflow
+  grants a write lock without exclusivity
+date: 2026-06-19
+description: |
+  ### Summary
+
+  `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.
+
+  ### Impact
+
+  This breaks the write-lock exclusivity guarantee. After the overflow,
+  a thread can be told it has acquired the write lock while other threads
+  can still hold or acquire read locks, allowing races and inconsistent
+  reads of protected mutable state.
+
+  ### Credit
+
+  Pranjali Thakur - depthfirst ([depthfirst.com](<http://depthfirst.com>))
+cvss_v4: 2.0
+patched_versions:
+  - ">= 1.3.7"
+related:
+  url:
+    - https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54905
+    - https://rubygems.org/gems/concurrent-ruby/versions/1.3.7
+    - https://github.com/ruby-concurrency/concurrent-ruby/releases/tag/v1.3.7
+    - https://advisories.gitlab.com/gem/concurrent-ruby/CVE-2026-54905
+    - https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-wv3x-4vxv-whpp
+    - https://github.com/advisories/GHSA-wv3x-4vxv-whpp
+notes: |
+  - cvss_v4 from GHSA
+  - CVE is reserved, but not published.
+    - Not on nvd.nist.gov so no cvss_v2 or cvss_v3.

gems/concurrent-ruby/CVE-2026-54906.yml

@@ -0,0 +1,55 @@
+---
+gem: concurrent-ruby
+cve: 2026-54906
+ghsa: 6wx8-w4f5-wwcr
+url: https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54906
+title: Concurrent Ruby - ReadWriteLock allows wrong-thread write
+  release and stray read-release counter corruption
+date: 2026-06-19
+description: |
+  ### Summary
+
+  `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. It should not be framed as an
+  authorization bypass; the lock is an in-process concurrency primitive,
+  not an access-control boundary.
+
+  ### Impact
+
+  This can break the write-lock mutual exclusion guarantee and can also
+  leave a lock unusable after a stray read release.
+  The impact is local to applications that expose or misuse the manual
+  `acquire_*` / `release_*` APIs. If the lock protects integrity-sensitive
+  mutable state, wrong-thread write release can allow concurrent writers
+  and data races. The stray read-release path can cause denial of service
+  by corrupting the lock counter.
+
+  ### Credit
+
+  Pranjali Thakur - depthfirst ([depthfirst.com](<http://depthfirst.com>))
+cvss_v4: 2.1
+patched_versions:
+  - ">= 1.3.7"
+related:
+  url:
+    - https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54906
+    - https://rubygems.org/gems/concurrent-ruby/versions/1.3.7
+    - https://github.com/ruby-concurrency/concurrent-ruby/releases/tag/v1.3.7
+    - https://advisories.gitlab.com/gem/concurrent-ruby/CVE-2026-54906
+    - https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-6wx8-w4f5-wwcr
+    - https://github.com/advisories/GHSA-6wx8-w4f5-wwcr
+notes: |
+  - cvss_v4 from GHSA
+  - CVE is reserved, but not published.
+    - Not on nvd.nist.gov so no cvss_v2 or cvss_v3.