Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#616 0 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 4 天内回复

@LeeroyHannigan 已经在做这个了。

开始于 2026年10月27日。

  • #619 来自 @LeeroyHannigan —— 未关闭

评估

这个 Issue 还没有评估数据。

描述

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.

主要语言
Rust
星标
517
派生
60
平均合并
4 天 10 小时
30 天内合并 PR
37

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

ExtendDB/extenddb 的其他 Issue

查看 ExtendDB/extenddb 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。