If a commit object has a header line at the end of the
buffer that is missing its newline (or if it appears so
because the content on the header line contains a stray
NUL), then git will segfault.
Interestingly, this case is explicitly handled and we do
correctly scan the final line for the header we are looking
for. But if we don't find it, we will dereference NULL while
trying to look at the next line.
Git will never generate such a commit, but it's good to be
defensive. We could die() in such a case, but since it's
easy enough to handle it gracefully, let's just issue a
warning and continue (so you could still view such a commit
with "git show", though you might be missing headers after
the NUL).
Signed-off-by: Jeff King <peff@xxxxxxxx>
---
I happened to notice this while experimenting with somebody else's
problem and generating a bogus commit with hash-object. I don't know of
any actual implementation which generates this particular bug.
pretty.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/pretty.c b/pretty.c
index 02a0a2b..dc57e5b 100644
--- a/pretty.c
+++ b/pretty.c
@@ -436,29 +436,32 @@ static void add_merge_info(const struct pretty_print_context *pp,
static char *get_header(const struct commit *commit, const char *key)
{
int key_len = strlen(key);
const char *line = commit->buffer;
- for (;;) {
+ while (line) {
const char *eol = strchr(line, '\n'), *next;
if (line == eol)
return NULL;
if (!eol) {
+ warning("malformed commit (header is missing newline): %s",
+ sha1_to_hex(commit->object.sha1));
eol = line + strlen(line);
next = NULL;
} else
next = eol + 1;
if (eol - line > key_len &&
!strncmp(line, key, key_len) &&
line[key_len] == ' ') {
return xmemdupz(line + key_len + 1, eol - line - key_len - 1);
}
line = next;
}
+ return NULL;
}
static char *replace_encoding_header(char *buf, const char *encoding)
{
struct strbuf tmp = STRBUF_INIT;
size_t start, len;
--
1.7.9.7.33.gc430a50
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html