summaryrefslogtreecommitdiff
path: root/t/t4013/diff.diff_initial..side
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2026-05-15 22:16:22 -0400
committerJunio C Hamano <gitster@pobox.com>2026-05-16 13:51:16 +0900
commit3ccb16052ae6096e4a0d5aede7af73f4ff4c1a82 (patch)
treecc23f9236d71155b2b5bd5a13079f3ba6a6a6d13 /t/t4013/diff.diff_initial..side
parent94f057755b7941b321fd11fec1b2e3ca5313a4e0 (diff)
apply: plug leak on "patch too large" error
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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t4013/diff.diff_initial..side')
0 files changed, 0 insertions, 0 deletions