Re: [PATCH 02/12] environment: move strbuf into block to plug leak

[Elijah Newren <newren@gmail.com>]

On Sun, Jun 20, 2021 at 8:14 AM <andrzej@ahunt.org> wrote:
>
> From: Andrzej Hunt <ajrhunt@google.com>
>
> realpath is only populated if we execute the git_work_tree_initialized
> block. However that block also causes us to return early, meaning we
> never actually release the strbuf in the case where we populated it.
> Therefore we move all strbuf related code into the block to guarantee
> that we can't leak it.
>
> LSAN output from t0095:
>
> Direct leak of 129 byte(s) in 1 object(s) allocated from:
>     #0 0x49a9b9 in realloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
>     #1 0x78f585 in xrealloc wrapper.c:126:8
>     #2 0x713ff4 in strbuf_grow strbuf.c:98:2
>     #3 0x713ff4 in strbuf_getcwd strbuf.c:597:3
>     #4 0x4f0c18 in strbuf_realpath_1 abspath.c:99:7
>     #5 0x5ae4a4 in set_git_work_tree environment.c:259:3
>     #6 0x6fdd8a in setup_discovered_git_dir setup.c:931:2
>     #7 0x6fdd8a in setup_git_directory_gently setup.c:1235:12
>     #8 0x4cb50d in get_bloom_filter_for_commit t/helper/test-bloom.c:41:2
>     #9 0x4cb50d in cmd__bloom t/helper/test-bloom.c:95:3
>     #10 0x4caa1f in cmd_main t/helper/test-tool.c:124:11
>     #11 0x4caded in main common-main.c:52:11
>     #12 0x7f0869f02349 in __libc_start_main (/lib64/libc.so.6+0x24349)
>
> SUMMARY: AddressSanitizer: 129 byte(s) leaked in 1 allocation(s).
>
> It looks like this leak has existed since realpath was first added to
> set_git_work_tree() in:
>   3d7747e318 (real_path: remove unsafe API, 2020-03-10)

Looking at that commit, it appears to have introduced other problems.
For example, the documentation for read_gitfile_gently() claims it
returns a value from a shared buffer, but that commit got rid of the
shared buffer so the documentation is no longer accurate.  The thing
that is returned is either the path that was passed in, or some newly
allocated path that differs, in which case the caller would be
responsible to free() it, but it looks like the callers aren't doing
so.  There may be others; as I didn't read the whole old patch, but it
looks like even this example could get messy.

I don't think you need to address the whole mess, fixing one of the
issues from it is fine and...

>
> Signed-off-by: Andrzej Hunt <andrzej@ahunt.org>
> ---
>  environment.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/environment.c b/environment.c
> index 2f27008424..d6b22ede7e 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -249,25 +249,24 @@ static int git_work_tree_initialized;
>  /*
>   * Note.  This works only before you used a work tree.  This was added
>   * primarily to support git-clone to work in a new repository it just
>   * created, and is not meant to flip between different work trees.
>   */
>  void set_git_work_tree(const char *new_work_tree)
>  {
> -       struct strbuf realpath = STRBUF_INIT;
> -
>         if (git_work_tree_initialized) {
> +               struct strbuf realpath = STRBUF_INIT;
> +
>                 strbuf_realpath(&realpath, new_work_tree, 1);
>                 new_work_tree = realpath.buf;
>                 if (strcmp(new_work_tree, the_repository->worktree))
>                         die("internal error: work tree has already been set\n"
>                             "Current worktree: %s\nNew worktree: %s",
>                             the_repository->worktree, new_work_tree);
> +               strbuf_release(&realpath);
>                 return;
>         }
>         git_work_tree_initialized = 1;
>         repo_set_worktree(the_repository, new_work_tree);
> -
> -       strbuf_release(&realpath);
>  }
>
>  const char *get_git_work_tree(void)
> --
> 2.26.2

This patch looks simple and correct.