In Puma before versions 3.12.2 and 4.3.1, a poorly-behaved client could use keepalive requests to monopolize Puma's reactor and create a denial of service attack. If more keepalive connections to Puma are opened than there are threads available, additional connections will wait permanently if the attacker sends requests frequently enough. This vulnerability is patched in Puma 4.3.1 and 3.12.2. References: https://github.com/puma/puma/security/advisories/GHSA-7xx3-m584-x994
Upstream Patch: https://github.com/puma/puma/commit/06053e60908074bb38293d4449ea261cb009b53e
Created rubygem-puma tracking bugs for this issue: Affects: fedora-all [bug 1831306]
Statement: Red Hat Gluster Storage Web Administration component uses affected RubyGem Puma. Added external reference and mitigation: On the external reference at workaround section there is information about possible vulnerability mitigation.
Statement: Red Hat CloudForms uses affected RubyGem Puma, however, not vulnerable since after increasing multiple keepalive connections compare to threads available; additional connections have not waited long. Red Hat Gluster Storage Web Administration component uses affected RubyGem Puma.
External References: https://github.com/puma/puma/security/advisories/GHSA-7xx3-m584-x994
Mitigation: Reverse proxies in front of Puma could be configured to always allow less than X keepalive connections to a Puma cluster or process, where X is the number of threads configured in Puma's thread pool.