-
Notifications
You must be signed in to change notification settings - Fork 388
httpc: fix signed integer overflow #8464
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
httpc: fix signed integer overflow #8464
Conversation
You have successfully added a new CodeQL configuration |
A cast of the value above 2^63-1 to `int64_t` has implementation defined behavior, see n1256, 6.3.1.3.3. `lua_pushinteger()` accepts `int64_t`, so passing `uint64_t` value may lead to pushing negative (or other incorrect) value. Let's use Tarantool specific `luaL_pushuint64()` function instead. This is mostly just to make things in the right way: it is unlikely to see such large values in the statistics in practice. See all the details in [1]. [1]: tarantool/tarantool#8464
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, Alexander!
Thanks for the patch!
LGTM, except a single nit regarding the commit message.
will be interpreted as a negative value on all architectures we're
support.
Typo: s/we're support/we're supporting/
The `lua_add_key_u64()` function pushes an `uint64_t` value using `lua_pushinteger()`, which accepts `int64_t` argument. A value >= 2^63 will be interpreted as a negative value on all architectures we're supporting. However, technically it is implementation defined behavior (see n1256, 6.3.1.3.3). It is not a problem, in fact, because the function is used only to report `http_client:stat()` statistics and because values beyond 2^63-1 are unreachable in practice. OTOH, it is easy to eliminate the undefined behavior by replacing `lua_pushinteger()` with our own helper function, which accepts `uint64_t`: `luaL_pushuint64()`. The values above 10^14 - 1 are now pushed as `cdata<uint64_t>`. Lower values are pushed as `number` just like before the commit. Reported-in: tarantool/security#103 NO_DOC=The type of values in the statistics is not specified explicitly in the documentation (not obligated to be `number`) and it is quite common for Tarantool to return a value of `cdata<int64_t>` or `cdata<uint64_t>` type for an integer with a large absolute value. NO_CHANGELOG=see NO_DOC NO_TEST=It is hard to reach so large values externally (send 2^63 requests) and it doesn't look worthful to introduce an error injection/a internal API to test it. `luaL_pushuint64()` is covered by the module API test.
5d57ad0
to
312ad3a
Compare
Fixed the typo. |
A cast of the value above 2^63-1 to `int64_t` has implementation defined behavior, see n1256, 6.3.1.3.3. `lua_pushinteger()` accepts `int64_t`, so passing `uint64_t` value may lead to pushing negative (or other incorrect) value. Let's use Tarantool specific `luaL_pushuint64()` function instead. This is mostly just to make things in the right way: it is unlikely to see such large values in the statistics in practice. See all the details in [1]. [1]: tarantool/tarantool#8464
Pushed to Not pushed to |
The
lua_add_key_u64()
function pushes anuint64_t
value usinglua_pushinteger()
, which acceptsint64_t
argument. A value >= 2^63 will be interpreted as a negative value on all architectures we're supporting. However, technically it is implementation defined behavior (see n1256, 6.3.1.3.3).It is not a problem, in fact, because the function is used only to report
http_client:stat()
statistics and because values beyond 2^63-1 are unreachable in practice.OTOH, it is easy to eliminate the undefined behavior by replacing
lua_pushinteger()
with our own helper function, which acceptsuint64_t
:luaL_pushuint64()
.The values above 10^14 - 1 are now pushed as
cdata<uint64_t>
. Lower values are pushed asnumber
just like before the commit.Reported-in: https://github.com/tarantool/security/issues/103