Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

An N value with an exponent near the i32 limits panics the number validator in debug builds and gets the wrong error in release builds

Abierto
  • ¿Algo no está bien?
#616 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 2 días

@LeeroyHannigan ya está trabajando en esto.

Desde el 27/10/2026.

  • #619 de @LeeroyHannigan — abierto

Evaluación

Este issue todavía no se ha evaluado.

Descripción

bug

Summary

validate_and_normalize_number in crates/core/src/validation/number.rs does its exponent arithmetic in unchecked i32. An N value whose exponent is near the i32 limits, such as 10E2147483647 or 1.5E-2147483648, overflows it. In a build with overflow checks on (the default for debug builds and cargo test) the request's worker thread panics and the client's connection closes with no response. Release builds keep Cargo's default of overflow checks off (the workspace Cargo.toml has no [profile.release] section), so the arithmetic wraps, and 10E2147483647 is refused as Number underflow, where Amazon DynamoDB answers Number overflow.

Measured (DynamoDB in us-east-1, 2026-10-27 08:42 to 08:44 UTC, each request sent twice, both rounds the same)

PutItem with a non-key attribute {"N": <value>}:

Value DynamoDB ExtendDB main abf8082f, debug build ExtendDB 0.1.14 dev image, release-slim profile (same number.rs as main)
10E2147483647 ValidationException 1 validation error detected: Number overflow. Attempting to store a number with magnitude larger than supported range connection closed, panicked at crates/core/src/validation/number.rs:86:15: attempt to add with overflow ValidationException Number underflow. Attempting to store a number with magnitude smaller than supported range
1.5E-2147483648 ValidationException 1 validation error detected: Number underflow. Attempting to store a number with magnitude smaller than supported range connection closed, panicked at crates/core/src/validation/number.rs:57:24: attempt to subtract with overflow ValidationException Number underflow. ...
1E2147483647 Number overflow. ... Number overflow. ... Number overflow. ...
1E99999999999999999999 The parameter cannot be converted to a numeric value: 1E99999999999999999999 the same the same
1E126, 1E-131, 1E125 (controls) overflow, underflow, accepted the same the same

The server keeps serving after the panic; only that request is lost.

DynamoDB starts each of these messages with 1 validation error detected: and ExtendDB starts none of them with it, controls included. That difference is not part of this issue.

Cause

The exponent is parsed as i32 (line 26). Three sums can then leave the i32 range:

  • line 57, explicit_exp - frac_part.len() as i32
  • line 86, point_offset + trailing_zeros as i32
  • line 90, sig_trimmed.len() as i32 - 1 + point_offset + trailing_zeros as i32

AttributeValue's Deserialize calls this function on each N value it decodes (crates/core/src/types/attribute_value.rs:107), so other operations that carry an N value reach it too. I measured PutItem only.

Exponent range (PutItem, twice each: DynamoDB 2026-10-27 08:50 to 08:52 UTC, ExtendDB main 09:40 UTC)

DynamoDB reads the exponent as a signed 64-bit integer. ExtendDB main parses it as an i32 and answers The parameter cannot be converted to a numeric value for anything wider.

Value DynamoDB ExtendDB main
1E2147483648, 1E4294967296, 1E9223372036854775807 Number overflow. ... cannot be converted
1E-2147483649, 1E-9223372036854775808 Number underflow. ... cannot be converted
1E9223372036854775808, 1E-9223372036854775809 The parameter cannot be converted to a numeric value: <value> the same

DynamoDB also range checks a zero on its exponent less its fraction digits (0E126 is Number overflow, 0.0E-130 is Number underflow), where ExtendDB's release builds accept every zero whose exponent fits in an i32 as 0 (a debug build panics on one such as 0.0E-2147483648, which the fix accepts as 0). That part depends on #618 and is left to it.

Fix

Parse the exponent as i64 and do the three sums in i128, where none of them can overflow. The order of magnitude then decides between Number overflow and Number underflow; that is DynamoDB's answer for every out-of-range value above except 0E126 and 0.0E-130, which are left to #618. A zero whose exponent does not fit in an i32 is range checked too, since main already refused those.

Found while reviewing #394, whose manifest parser also calls this function on untrusted input.

Lenguaje dominante
Rust
Estrellas
517
Forks
60
Merge medio
2 d 22 h
PR fusionados (30 d)
25

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ExtendDB/extenddb

Todos los issues de ExtendDB/extenddb

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.