Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue 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

Aperta
  • Qualcosa non va?
#616 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@LeeroyHannigan ci sta già lavorando.

Dal 27/10/2026.

  • #619 di @LeeroyHannigan — aperta

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

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.

Lingua principale
Rust
Stelle
517
Fork
60
Merge medio
2g 22h
PR unite (30g)
25

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ExtendDB/extenddb

Tutte le issue di ExtendDB/extenddb

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.