Re: [PATCH] revision: fix missing null for freed memory

[Junio C Hamano <gitster@pobox.com>]

Emily M Klassen <forivall@gmail.com> writes:

> "git log --graph --no-graph" missed cleaning up the output_prefix and
> output_prefix_data pointers. This resulted in a segfault when using "--patch",
> "--name-status" or "--name-only", as the output_prefix_data continued to be in
> use after free()
>
> Signed-off-by: Emily M Klassen <forivall@gmail.com>
> ---
> I previously reported this a few hours ago, and ended up digging in and figuring
> it out. I'll make sure to bottom reply in the follow ups to this patch.
>
>  revision.c | 2 ++
>  1 file changed, 2 insertions(+)

Reading the symptom in the proposed log message (which is very
clearly written, by the way), it seems that this is reproducible?

Can we have a test to make sure that the fix would not be broken
later?

> diff --git a/revision.c b/revision.c
> index 474fa1e767..84cb028e11 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -2615,6 +2615,8 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
>  		graph_clear(revs->graph);
>  		revs->graph = graph_init(revs);
>  	} else if (!strcmp(arg, "--no-graph")) {
> +		revs->diffopt.output_prefix = NULL;
> +		revs->diffopt.output_prefix_data = NULL;
>  		graph_clear(revs->graph);
>  		revs->graph = NULL;
>  	} else if (!strcmp(arg, "--encode-email-headers")) {

Interesting.

In response to "--graph" (the code we can see in the context before
this part), we clear the revs->graph and then call graph_init(revs)
for ourselves, and we do not have to futz with diffopt at all, and
it works OK because output_prefix_data and output_prefix would be
overwritten by the graph_init() to the value we want to use anyway.

But of course, after "--no-graph", nobody clears these two members
for us, so we'd need to clear them here.

It might make the API less error-prone if the "clear" function
cleared the .graph and diffopt->output_prefix{,_data} together
but among three existing callers of graph_clear(), only this caller
needs to clear these two members, so it probably would not matter.

So in short, this seems to be a good fix for the immediate issue,
and it is unlikely that we'd need any follow-up work.