aboutsummaryrefslogtreecommitdiffstats
path: root/builtin/commit.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2019-08-25 04:08:21 -0400
committerJunio C Hamano <gitster@pobox.com>2019-08-27 15:02:49 -0700
commit9756082b3cfaf69574bc3283cf4c9ba9c91442bc (patch)
treed7ee74108438064f41cdceae893a15c665b7d203 /builtin/commit.c
parentFirst batch after Git 2.23 (diff)
downloadgit-9756082b3cfaf69574bc3283cf4c9ba9c91442bc.tar.gz
git-9756082b3cfaf69574bc3283cf4c9ba9c91442bc.zip
fast-import: duplicate parsed encoding string
We read each line of the fast-import stream into the command_buf strbuf. When reading a commit, we parse a line like "encoding foo" by storing a pointer to "foo", but not making a copy. We may then read an unbounded number of other lines (e.g., one for each modified file in the commit), each of which writes into command_buf. This works out in practice for small cases, because we hand off ownership of the heap buffer from command_buf to the cmd_hist array, and read new commands into a fresh heap buffer. And thus the pointer to "foo" remains valid as long as there aren't so many intermediate lines that we end up dropping the original "encoding" line from the history. But as the test modification shows, if we go over our default of 100 lines, we end up with our encoding string pointing into freed heap memory. This seems to fail reliably by writing garbage into the output, but running under ASan definitely detects this as a use-after-free. We can fix it by duplicating the encoding value, just as we do for other parsed lines (e.g., an author line ends up in parse_ident, which copies it to a new string). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin/commit.c')
0 files changed, 0 insertions, 0 deletions