fix(math): bound pow_factor's integer-power loop - #702
Merged
IbrahimIjai merged 1 commit intoAug 31, 2026
Merged
Conversation
) pow_factor's `whole` exponent came straight from data_store config with no upper bound, so a misconfigured funding/borrowing/price-impact exponent factor could drive an O(whole)-iteration loop large enough to exhaust the CPU budget on every call that reaches it. Reject any whole exponent above 10 (GMX-style factors are conventionally 1.0-3.0), and add regression tests for both the rejection and the inclusive boundary.
|
@dev-debbie-umoh Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
gmx_math::pow_factor's integer-power loop iteratedexponent / FLOAT_PRECISIONtimes with no upper bound. Funding/borrowing/price-impact exponent factors are read straight fromdata_storeconfig with no validation, so a misconfigured value (admin typo, script bug, wrong-precision value) could drive a loop large enough to exhaust the CPU budget on every order execution, funding update, or price-impact calculation that touches the affected market — a self-inflicted denial of service.Fix
MAX_POW_FACTOR_WHOLE_EXPONENT = 10(GMX-style exponent factors are conventionally 1.0–3.0) and reject any exponent whose whole part exceeds it, before the loop runs.Closes #538
Test plan
cargo test -p gmx-math— 30 passed, 0 failedgrep -n "TODO"n/a — this issue had no stub, straightforward bound addition