Copyright © 2012 Red Hat, Inc. All rights reserved. Moderate 2026-06-24T15:44:21 concurrent-ruby: rubygem-concurrent-ruby: concurrent-ruby: Denial of Service due to infinite loop in AtomicReference#update 5.9 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H CWE-835

concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, 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.; and 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. This vulnerability is fixed in 1.3.7.

A flaw was found in concurrent-ruby. A remote attacker could exploit a vulnerability in the Concurrent::AtomicReference#update method, which can enter a permanent busy retry loop. This occurs when the current value is a special 'Not a Number' (Float::NAN) floating-point value, causing the method to repeatedly attempt an operation without success. This can lead to a Denial of Service (DoS), where the affected application experiences CPU exhaustion or becomes unresponsive.

The issue arises when the `AtomicReference#update` method encounters a `Float::NAN` value, leading to an infinite retry loop and potential CPU exhaustion. The vulnerable `AtomicReference#update` method is not used with externally-controlled (e.g: `Float::NAN`) values - thus exploitation is not possible. The vulnerable `AtomicReference#update` code path is not exercised with externally-derived numeric values, making exploitation not possible in this context. Updating to concurrent-ruby 1.3.7 when available in upstream dependencies will fully resolve this issue. Red Hat 3scale API Management Platform 2 Not affected 3scale-amp21/backend Red Hat 3scale API Management Platform 2 Not affected 3scale-amp21/system Red Hat 3scale API Management Platform 2 Not affected 3scale-amp21/zync Red Hat 3scale API Management Platform 2 Not affected 3scale-amp22/backend Red Hat 3scale API Management Platform 2 Not affected 3scale-amp22/system Red Hat 3scale API Management Platform 2 Not affected 3scale-amp22/zync Red Hat 3scale API Management Platform 2 Not affected 3scale-amp26/toolbox Red Hat 3scale API Management Platform 2 Not affected 3scale-amp2/backend-rhel8 Red Hat 3scale API Management Platform 2 Not affected 3scale-amp2/system-rhel7 Red Hat 3scale API Management Platform 2 Not affected 3scale-amp2/system-rhel8 Red Hat 3scale API Management Platform 2 Not affected 3scale-amp2/system-rhel9 Red Hat 3scale API Management Platform 2 Not affected 3scale-amp2/toolbox-rhel8 Red Hat 3scale API Management Platform 2 Not affected 3scale-amp2/toolbox-rhel9 Red Hat 3scale API Management Platform 2 Not affected 3scale-amp2/zync-rhel8 Red Hat 3scale API Management Platform 2 Not affected 3scale-amp2/zync-rhel9 Red Hat OpenStack Platform 17.1 Not affected rubygem-concurrent-ruby Red Hat Satellite 6 Not affected rubygem-concurrent-ruby Red Hat Satellite 6 Not affected satellite:el8/rubygem-concurrent-ruby https://www.cve.org/CVERecord?id=CVE-2026-54904 https://nvd.nist.gov/vuln/detail/CVE-2026-54904 https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-h8w8-99g7-qmvj