Contrived integer overflows #1094
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If it was 0 for some reason, we force it to be UINT_MAX instead, exactly to avoid such checks at run time.
Some variable values come from a configuration file, and can be arbitrary. Then, some additional care is needed to prevent overflows.
Since time_t is a 64-bit type, in some contrived cases it's possible to overflow 32-bit integer. Let's use 64-bit instead.
It's compared to tfw_http_req_t::retries, which is unsigned short. So there are no sense in values larger than USHRT_MAX
vankoven
approved these changes
Nov 8, 2018
| @@ -1909,9 +1909,11 @@ tfw_vhost_start(void) | |||
| if (!tfw_runstate_is_reconfig()) { | |||
| /* Convert Frang global timeouts to jiffies for convenience */ | |||
| frang_cfg.clnt_hdr_timeout = | |||
| *(unsigned int *)&frang_cfg.clnt_hdr_timeout * HZ; | |||
| *(unsigned int *)&frang_cfg.clnt_hdr_timeout * | |||
There was a problem hiding this comment.
First I wanted to write, that:
- it's rather hacky to work with unsigned long as
*(unsigned int *)&, no problems on x86, but still not good, - actual code that parses
client_header_timeoutdirective is split into two functions without any need, - there is no allowed range specified for
client_header_timeoutdirective and negative values are possible, - the code in
http_limits.cexpect jiffies in all cases, not only for global limits.
But then I've looked more, why only global timeout is converted to jiffes, but not for the other locations. It turns out, that per-vhost clnt_hdr_timeout limit is never used. It's architectural feature: we can't choose target vhost until the whole header is parsed, and this global limit will be applied to all vhosts. In the same time clnt_body_timeout limit for non-default locations will be much more strict that required.
Don't need to fix this issues in this PR, let's revise the correctness of all the frang limits in #1028
aleksostapenko
approved these changes
Nov 8, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In some cases it's possible to specify numbers in the configuration file that may cause integer overflows. In such cases timeouts, for example, may be different from expected. Explicit up-casting before multiplications should prevent that.
fixes #1091