https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 13:25:51 +0000 https://cve.radiocsirt.org/vuln/brew-asciidoctor-cve-2026-54905 <p><strong>Affected:</strong> Homebrew: asciidoctor</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&#39;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> <p><strong>Affected:</strong> Homebrew: asciidoctor</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&#39;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> https://cve.radiocsirt.org/vuln/brew-asciidoctor-cve-2026-54905 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0958 certfr-2026-avi-0958 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0958 https://cve.radiocsirt.org/vuln/cleanstart-2026-ch23308 <p><strong>Affected:</strong> CleanStart: logstash-fips, CleanStart: ruby-fluentd-1.18, CleanStart: ruby-fluentd-1.19</p> <p>CVE-2026-54905 affects multiple packages. This issue is resolved in later releases. See references for individual vulnerability details.</p> <p><strong>Affected:</strong> CleanStart: logstash-fips, CleanStart: ruby-fluentd-1.18, CleanStart: ruby-fluentd-1.19</p> <p>CVE-2026-54905 affects multiple packages. This issue is resolved in later releases. See references for individual vulnerability details.</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-ch23308 https://cve.radiocsirt.org/vuln/euvd-2026-330001 EUVD-2026-330001 https://cve.radiocsirt.org/vuln/euvd-2026-330001 https://cve.radiocsirt.org/vuln/fkie_cve-2026-54905 <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&#39;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> <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&#39;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> https://cve.radiocsirt.org/vuln/fkie_cve-2026-54905 https://cve.radiocsirt.org/vuln/ghsa-wv3x-4vxv-whpp <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&#39;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> <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&#39;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> https://cve.radiocsirt.org/vuln/ghsa-wv3x-4vxv-whpp https://cve.radiocsirt.org/vuln/msrc_cve-2026-54905 msrc_CVE-2026-54905 https://cve.radiocsirt.org/vuln/msrc_cve-2026-54905 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54905 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: ruby-concurrent, Ubuntu:18.04:LTS: ruby-concurrent, Ubuntu:20.04:LTS: ruby-concurrent, Ubuntu:22.04:LTS: ruby-concurrent, Ubuntu:24.04:LTS: ruby-concurrent, Ubuntu:25.10: ruby-concurrent, Ubuntu:26.04:LTS: ruby-concurrent</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&#39;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> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: ruby-concurrent, Ubuntu:18.04:LTS: ruby-concurrent, Ubuntu:20.04:LTS: ruby-concurrent, Ubuntu:22.04:LTS: ruby-concurrent, Ubuntu:24.04:LTS: ruby-concurrent, Ubuntu:25.10: ruby-concurrent, Ubuntu:26.04:LTS: ruby-concurrent</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&#39;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> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54905