fix signed-integer overflow in git_config_parse_int64() - #7344
Merged
ethomson merged 1 commit intoAug 12, 2026
Merged
Conversation
git_config_parse_int64()
Member
|
Thanks. This is one of the better AI generated bug reports so far, in terms of clarity, readability, and actionability. |
ethomson
approved these changes
Aug 12, 2026
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
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.
This PR attempts to fix #7343
Problem
git_config_parse_int64()insrc/libgit2/config.capplies ak/m/gsize suffix through a fallthroughswitchthat runsnum *= 1024up to three times with no overflow check:When an input parses cleanly as an
int64_tbut its suffix-scaled result exceedsINT64_MAX, this is signed-integer overflow (UB, flagged by UBSan), and — worse — the function falls through to*out = num; return 0;, returning success with a silently-wrapped garbage value:Fix
Gate each
num *= 1024on the existinggit__multiply_int64_overflowhelper — the same onegit__strntol64uses for digit accumulation — and bail to the existingfail_parselabel on overflow:This uses the helper rather than a hand-rolled
if (num > INT64_MAX / 1024)guard for two reasons:-5g→num < 0). A positive-onlyINT64_MAX / 1024bound would not catchINT64_MIN * 1024underflow.git__multiply_int64_overflowis defined for the full signed range.src/util/integer.h) for free.No new
#includeis needed —git__strntol64is already called in this function, so the integer helpers are already in scope. Routing overflow through the existingfail_parselabel keeps the error message consistent with other parse failures ("failed to parse '...' as an integer") and returns-1, exactly the documented "error code" outcome.In-range values are unchanged; only the previously-UB cases now return
-1.git_config_parse_int32is fixed transitively.1Gret=0, out=1073741824ret=0, out=1073741824(unchanged)51539607552Gret=0, out=0(UB, garbage)ret=-1(error)9223372036854775807Gret=0, out=-1073741824(UB, garbage)ret=-1(error)Verification
Sanitizer rebuild
Rebuilt libgit2 with AddressSanitizer and UndefinedBehaviorSanitizer to confirm the overflow is gone:
Before fix:
After fix:
(clean exit, no sanitizer errors —
git_config_parse_int64returns-1for the overflowing inputs)Test-suite results
Ran the libgit2 test suite under ASan + UBSan with
halt_on_error=1:libgit2_clar(config parsing tests)libgit2_clar(full suite)All tests pass with the fix applied; existing in-range suffix behavior (
1g,512m, etc.) is unchanged.