This started happening on 'next' that runs EXPENSIVE tests thanks to Dscho's recent updates to enable them in CI.

https://github.com/git/git/actions/runs/25896439353/job/76110441841#step:10:2172

It claims that """

    commit.c:1574:6: runtime error: signed integer overflow:
    -2147483648 - 1 cannot be represented in type 'int'

""".

Another is related in the sense that it used to be hidden behind EXPENSIVE prerequisite, but is probably unrelated.

https://github.com/git/git/actions/runs/25896439353/job/76110441842#step:10:156

On Sat, May 16, 2026 at 08:43:07AM +0900, Junio C Hamano wrote:

These patches should fix both.

  [1/2]: apply: plug leak on "patch too large" error
  [2/2]: commit: handle large commit messages in utf8 verification

 apply.c  |  6 ++++--
 commit.c | 31 +++++++++++++++----------------
 2 files changed, 19 insertions(+), 18 deletions(-)

-Peff

In apply_patch(), we return immediately if read_patch_file() returns an error. Traditionally this was OK, since an error from strbuf_read() would restore the strbuf to its unallocated state.

But since f1c0e3946e (apply: reject patches larger than ~1 GiB, 2022-10-25), we may also return an error if we successfully read the patch but it is too large. In this case we leak the strbuf contents when apply_patch() returns.

You can see it in action by running t4141 under LSan with the EXPENSIVE prereq enabled.

We can fix this in one of two places:

  1. In read_patch_file(), we could release the buffer before returning
     the error, behaving more like a raw strbuf_read() call.

  2. In apply_patch(), we can release the strbuf ourselves before
     returning.

I picked the latter, since it future proofs us against read_patch_file() getting new error modes. We also have a cleanup label in that function already, so now our error handling at this spot matches the rest of the function (and all of the variables are initialized such that the rest of the cleanup is correctly a noop at this point).

Signed-off-by: Jeff King <peff@peff.net>
---
 apply.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Running t4205 under UBSan with the EXPENSIVE prereq enabled triggers an error when we try to create a commit message that is over 2GB:

  commit.c:1574:6: runtime error: signed integer overflow:
    -2147483648 - 1 cannot be represented in type 'int'

The problem is that find_invalid_utf8() is not prepared to handle large buffers, as it uses an "int" to represent buffer sizes and offsets.

We can fix this with a few changes:

  1. We'll take in "len" as a size_t (which is what the caller has
     anyway, since it's working with a strbuf).

  2. We need to return a size_t to give the offset to the invalid utf8,
     but we also need a sentinel value for "no invalid value"
     (previously "-1"). Let's split these to return a bool for "found
     invalid utf8" and then pass back the offset as an out-parameter.
     We'll switch the function name to match the new semantics.

  3. The caller in verify_utf8() uses a "long" to store buffer
     positions, which is a bit funny. This goes back to 08a94a145c
     (commit/commit-tree: correct latin1 to utf-8, 2012-06-28) and is
     perhaps trying to match our use of "unsigned long" for object sizes
     (though we don't care about it ever becoming negative here). This
     should be a size_t, too, as some platforms (like Windows) still use
     a 32-bit long on machines with 64-bit pointers.

  4. The "bytes" field within find_invalid_utf() does not have range
     problems. It is the number of bytes the utf8 sequence claims to
     have, so is limited by how many bits can be set in a single 8-bit
     byte. However, if we leave it as an "int" then the compiler will
     complain about the sign mismatch when comparing it to "len". So
     let's make it unsigned, too.

All of this is a little silly, of course, because 2GB text commit messages are clearly nonsense. So we might consider rejecting them outright, but it is easy enough to make these helper functions more robust in the meantime.

Signed-off-by: Jeff King <peff@peff.net>
---
I tried to look carefully for any reasons why these variables could ever
be negative, but beyond the sentinel value in the return type, didn't
see one. But reviewers should double check. Note that "bad_offset =
offset-1" in the context looks suspicious, but we are guaranteed that
offset has been advanced at this point.

 commit.c | 31 +++++++++++++++----------------
 1 file changed, 15 insertions(+), 16 deletions(-)

On 5/15/26 10:13 PM, Jeff King wrote:

Thanks for the fast fixes. I agree with you that 2GB commit messages are silly, but the methods you change could be used for other things so having better types is good. We can consider blocking large commits as a feature another time.

-Stolee