From d72cae12b9a7bba3a6626e0b5805955eafdefcc6 Mon Sep 17 00:00:00 2001 From: Jeff King Date: Fri, 19 May 2017 08:52:25 -0400 Subject: get_sha1_with_context: always initialize oc->symlink_path The get_sha1_with_context() function zeroes out the oc->symlink_path strbuf, but doesn't use strbuf_init() to set up the usual invariants (like pointing to the slopbuf). We don't actually write to the oc->symlink_path strbuf unless we call get_tree_entry_follow_symlinks(), and that function does initialize it. However, readers may still look at the zero'd strbuf. In practice this isn't a triggerable bug. The only caller that looks at it only does so when the mode we found is 0. This doesn't happen for non-tree-entries (where we return S_IFINVALID). A broken tree entry could have a mode of 0, but canon_mode() quietly rewrites that into S_IFGITLINK. So the "0" mode should only come up when we did indeed find a symlink. This is mostly just an accident of how the code happens to work, though. Let's future-proof ourselves to make sure the strbuf is properly initialized for all calls (it's only a few struct member assignments, not a heap allocation). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano diff --git a/sha1_name.c b/sha1_name.c index 179f214..e7b0393 100644 --- a/sha1_name.c +++ b/sha1_name.c @@ -1511,6 +1511,7 @@ static int get_sha1_with_context_1(const char *name, memset(oc, 0, sizeof(*oc)); oc->mode = S_IFINVALID; + strbuf_init(&oc->symlink_path, 0); ret = get_sha1_1(name, namelen, sha1, flags); if (!ret) return ret; diff --git a/tree-walk.c b/tree-walk.c index ff77605..c7ecfc8 100644 --- a/tree-walk.c +++ b/tree-walk.c @@ -589,7 +589,6 @@ enum follow_symlinks_result get_tree_entry_follow_symlinks(unsigned char *tree_s int i; init_tree_desc(&t, NULL, 0UL); - strbuf_init(result_path, 0); strbuf_addstr(&namebuf, name); hashcpy(current_tree_sha1, tree_sha1); -- cgit v0.10.2-6-g49f6