{"id":"CVE-2026-54906","title":"Concurrent Ruby: ReadWriteLock allows wrong-thread write release and stray read-release counter corruption","summary":"Concurrent Ruby: ReadWriteLock allows wrong-thread write release and stray read-release counter corruption","severity":"low","cwe":["CWE-414","CWE-667"],"vendor":"concurrent-ruby","product":"concurrent-ruby","ecosystem":"rubygems","affected":["concurrent-ruby < 1.3.7"],"patched":["concurrent-ruby 1.3.7"],"published":"2026-06-19","updated":"2026-06-19","source":"GHSA","sourceUrl":"https://github.com/advisories/GHSA-6wx8-w4f5-wwcr","references":[{"url":"https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-6wx8-w4f5-wwcr"},{"url":"https://github.com/advisories/GHSA-6wx8-w4f5-wwcr"}],"tags":["ghsa","rubygems"],"epss":0.00252,"epssPercentile":0.14825,"ingestedAt":"2026-06-22T13:35:24.397Z","slug":"CVE-2026-54906","body":"## Overview\n\n### 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) > 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) && 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 - <<'RUBY'\nrequire 'concurrent/atomic/read_write_lock'\nrequire 'concurrent/version'\nrequire 'thread'\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 << :writer1_acquired\n  sleep 0.5\n  writer1_inside = false\n  lock.release_write_lock\n  events << :writer1_finished\nend\n\nevents.pop\nputs 'writer1_acquired=true'\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  'acquired'\nrescue => 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 && writer2_entered_while_writer1_inside && counter_after_stray_read_release == -1\n  puts 'result=REPRODUCED wrong-thread write release and stray read-release corruption'\nelse\n  puts 'result=NOT_REPRODUCED'\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](<http://depthfirst.com>))\n\n## Affected packages\n\n- `concurrent-ruby < 1.3.7`\n\n## Remediation\n\nUpgrade to a patched release:\n\n- `concurrent-ruby 1.3.7`","depth":"sunlit","depthScore":14,"depthScoreParts":{"impact":13.8,"likelihood":0.1,"exploitation":0,"ransomware":0},"changes":[]}