<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T21:07:33.268667+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-54905</id>
    <title>CVE-2026-54905 — concurrent-ruby:  `ReentrantReadWriteLock` read-count overflow grants a write lock without exclusivity</title>
    <updated>2026-09-30T21:07:33.335014+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> ruby-concurrency concurrent-ruby</p>
<p>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.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-54905"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-wv3x-4vxv-whpp</id>
    <title>GHSA-wv3x-4vxv-whpp — Concurrent Ruby: `ReentrantReadWriteLock` read-count overflow grants a write lock without exclusivity</title>
    <updated>2026-09-30T21:07:33.335142+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> RubyGems: concurrent-ruby</p>
<p>### Summary
`Concurrent::ReentrantReadWriteLock` can incorrectly grant a write lock after one thread acquires the read lock 32,768 times.</p>
<p>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.</p>
<p>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.</p>
<p>### Version
Software: concurrent-ruby
Version: 1.3.6
Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab</p>
<p>### Details</p>
<p>The implementation uses a shared counter to track global readers/writers and a per-thread local counter to support reentrancy:</p>
<p>```ruby
READER_BITS    = 15
WRITER_BITS    = 14</p>
<p>WAITING_WRITER = 1 &lt;&lt; READER_BITS
RUNNING_WRITER = 1 &lt;&lt; (READER_BITS + WRITER_BITS)
MAX_READERS    = WAITING_WRITER - 1
MAX_WRITERS    = RUNNING_WRITER - MAX_READERS - 1</p>
<p>WRITE_LOCK_HELD = 1 &lt;&lt; READER_BITS
READ_LOCK_MASK  = WRITE_LOCK_HELD - 1
WRITE_LOCK_MASK = MAX_WRITERS
```</p>
<p>When a thread already holds a lock, `acquire_read_lock` increments `@HeldCount`:</p>
<p>```ruby
if (held = @HeldCount.value) &gt; 0
  if held &amp; READ_LOCK_MASK == 0
    @Counter.update { |c| c + 1 }
  end
  @HeldCount.value = held…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-wv3x-4vxv-whpp"/>
  </entry>
</feed>
