Description
Memory Allocation with Excessive Size Value vulnerability in ericmj decimal allows Denial of Service.
Decimal.round/3 builds the full result for the requested number of decimal places before the context precision (34 digits by default) is applied, so its cost grows with the places argument instead of with the size of the result. For positive places it appends places zero digits to the coefficient as a charlist before converting it to an integer, and for negative places it builds a charlist of -places zero digits. A single call such as Decimal.round(Decimal.new("1.5"), -50_000_000) allocates about 5.5 GB of memory, which can exhaust available memory and get the BEAM VM killed. The oldest releases instead loop once per decimal place, consuming CPU in proportion to places.
Any application that passes a user-supplied number of decimal places or scale to Decimal.round/2 or Decimal.round/3 without bounding it is exposed. The input limits added for CVE-2026-32686 do not cover the places argument.
This issue affects decimal: from 0.1.0 before 3.1.2.
Decimal.round/3 builds the full result for the requested number of decimal places before the context precision (34 digits by default) is applied, so its cost grows with the places argument instead of with the size of the result. For positive places it appends places zero digits to the coefficient as a charlist before converting it to an integer, and for negative places it builds a charlist of -places zero digits. A single call such as Decimal.round(Decimal.new("1.5"), -50_000_000) allocates about 5.5 GB of memory, which can exhaust available memory and get the BEAM VM killed. The oldest releases instead loop once per decimal place, consuming CPU in proportion to places.
Any application that passes a user-supplied number of decimal places or scale to Decimal.round/2 or Decimal.round/3 without bounding it is exposed. The input limits added for CVE-2026-32686 do not cover the places argument.
This issue affects decimal: from 0.1.0 before 3.1.2.
No analysis available yet.
Remediation
Vendor Workaround
Bound places before calling Decimal.round/2,3, for example to -34..34 or to the scales the application supports.
Tracking
Sign in to view the affected projects.
Advisories
No advisories yet.
References
History
Sat, 10 Oct 2026 20:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | Memory Allocation with Excessive Size Value vulnerability in ericmj decimal allows Denial of Service. Decimal.round/3 builds the full result for the requested number of decimal places before the context precision (34 digits by default) is applied, so its cost grows with the places argument instead of with the size of the result. For positive places it appends places zero digits to the coefficient as a charlist before converting it to an integer, and for negative places it builds a charlist of -places zero digits. A single call such as Decimal.round(Decimal.new("1.5"), -50_000_000) allocates about 5.5 GB of memory, which can exhaust available memory and get the BEAM VM killed. The oldest releases instead loop once per decimal place, consuming CPU in proportion to places. Any application that passes a user-supplied number of decimal places or scale to Decimal.round/2 or Decimal.round/3 without bounding it is exposed. The input limits added for CVE-2026-32686 do not cover the places argument. This issue affects decimal: from 0.1.0 before 3.1.2. | |
| Title | Unbounded allocation in decimal Decimal.round/3 driven by the places argument enables DoS | |
| First Time appeared |
Ericmj
Ericmj decimal |
|
| Weaknesses | CWE-789 | |
| CPEs | cpe:2.3:a:ericmj:decimal:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Ericmj
Ericmj decimal |
|
| References |
|
|
| Metrics |
cvssV4_0
|
Status: PUBLISHED
Assigner: EEF
Published:
Updated: 2026-10-10T19:43:45.217Z
Reserved: 2026-10-09T00:30:01.645Z
Link: CVE-2026-97853
No data.
Status : Received
Published: 2026-10-10T20:16:47.640
Modified: 2026-10-10T20:16:47.640
Link: CVE-2026-97853
No data.
OpenCVE Enrichment
No data.
Weaknesses
-
CWE-789
Memory Allocation with Excessive Size Value