threads / patch / 53392

patchcommit-graph: avoid memory leaks

Subject: [PATCH] commit-graph: avoid memory leaks

## tl;dr

4 messages between May 4, 2020 and May 4, 2020. Diffs are folded; open one to read it.

replies: 3people: 4as markdown or json

Jonathan Tan· May 4, 2020, 19:13 UTC · lore

A fuzzer running on the entry point provided by fuzz-commit-graph.c revealed a memory leak when parse_commit_graph() creates a struct bloom_filter_settings and then returns early due to error. Fix that error by always freeing that struct first (if it exists) before returning early due to error.

While making that change, I also noticed another possible memory leak - when the BLOOMDATA chunk is provided but not BLOOMINDEXES. Also fix that error.

Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
---
Here's a memory leak fix revealed by a fuzzer running at $DAYJOB, and
another one that I noticed while making that fix.
---
 commit-graph.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)
Show changes to commit-graph.c +11 −11
diff --git a/commit-graph.c b/commit-graph.c
index 6dc777e2f3..1694f0a691 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -281,8 +281,7 @@ struct commit_graph *parse_commit_graph(void *graph_map, size_t graph_size)
 		if (data + graph_size - chunk_lookup <
 		    GRAPH_CHUNKLOOKUP_WIDTH) {
 			error(_("commit-graph chunk lookup table entry missing; file may be incomplete"));
-			free(graph);
-			return NULL;
+			goto free_and_return;
 		}
 
 		chunk_id = get_be32(chunk_lookup + 0);
@@ -293,8 +292,7 @@ struct commit_graph *parse_commit_graph(void *graph_map, size_t graph_size)
 		if (chunk_offset > graph_size - the_hash_algo->rawsz) {
 			error(_("commit-graph improper chunk offset %08x%08x"), (uint32_t)(chunk_offset >> 32),
 			      (uint32_t)chunk_offset);
-			free(graph);
-			return NULL;
+			goto free_and_return;
 		}
 
 		switch (chunk_id) {
@@ -361,8 +359,7 @@ struct commit_graph *parse_commit_graph(void *graph_map, size_t graph_size)
 
 		if (chunk_repeated) {
 			error(_("commit-graph chunk id %08x appears multiple times"), chunk_id);
-			free(graph);
-			return NULL;
+			goto free_and_return;
 		}
 
 		if (last_chunk_id == GRAPH_CHUNKID_OIDLOOKUP)
@@ -381,17 +378,20 @@ struct commit_graph *parse_commit_graph(void *graph_map, size_t graph_size)
 		/* We need both the bloom chunks to exist together. Else ignore the data */
 		graph->chunk_bloom_indexes = NULL;
 		graph->chunk_bloom_data = NULL;
-		graph->bloom_filter_settings = NULL;
+		FREE_AND_NULL(graph->bloom_filter_settings);
 	}
 
 	hashcpy(graph->oid.hash, graph->data + graph->data_len - graph->hash_len);
 
-	if (verify_commit_graph_lite(graph)) {
-		free(graph);
-		return NULL;
-	}
+	if (verify_commit_graph_lite(graph))
+		goto free_and_return;
 
 	return graph;
+
+free_and_return:
+	free(graph->bloom_filter_settings);
+	free(graph);
+	return NULL;
 }
 
 static struct commit_graph *load_commit_graph_one(const char *graph_file,
-- 
2.26.2.526.g744177e7f7-goog
Derrick Stolee· May 4, 2020, 20:20 UTC · re: Jonathan Tan · lore

Re: [PATCH] commit-graph: avoid memory leaks

On 5/4/2020 3:13 PM, Jonathan Tan wrote:
Show 5 quoted lines
> A fuzzer running on the entry point provided by fuzz-commit-graph.c
> revealed a memory leak when parse_commit_graph() creates a struct
> bloom_filter_settings and then returns early due to error. Fix that
> error by always freeing that struct first (if it exists) before
> returning early due to error.

This fuzzer is an excellent tool that I hope can continue to be extended to other features. Here is a case where it found an error in a feature long after the integration was introduced.

> While making that change, I also noticed another possible memory leak -
> when the BLOOMDATA chunk is provided but not BLOOMINDEXES. Also fix that
> error.
Thanks for discovering these issues, and for fixing them!
Reviewed-by: Derrick Stolee <dstolee@microsoft.com>

Thanks, -Stolee

Taylor Blau· May 4, 2020, 22:15 UTC · re: Derrick Stolee · lore

Re: [PATCH] commit-graph: avoid memory leaks

On Mon, May 04, 2020 at 04:20:41PM -0400, Derrick Stolee wrote:
Show 18 quoted lines
> On 5/4/2020 3:13 PM, Jonathan Tan wrote:
> > A fuzzer running on the entry point provided by fuzz-commit-graph.c
> > revealed a memory leak when parse_commit_graph() creates a struct
> > bloom_filter_settings and then returns early due to error. Fix that
> > error by always freeing that struct first (if it exists) before
> > returning early due to error.
>
> This fuzzer is an excellent tool that I hope can continue to be
> extended to other features. Here is a case where it found an error in
> a feature long after the integration was introduced.
>
> > While making that change, I also noticed another possible memory leak -
> > when the BLOOMDATA chunk is provided but not BLOOMINDEXES. Also fix that
> > error.
>
> Thanks for discovering these issues, and for fixing them!
>
> Reviewed-by: Derrick Stolee <dstolee@microsoft.com>

Since it already appears to be queued, I'm not sure that my review is adding much. But, this fix looks very good to me, and I am grateful for you running a fuzzer against this code, and finding/fixing bugs in it.

  Reviewed-by: Taylor Blau <me@ttaylorr.com>
> Thanks,
> -Stolee

Thanks, Taylor

Junio C Hamano· May 4, 2020, 21:09 UTC · re: Jonathan Tan · lore

Re: [PATCH] commit-graph: avoid memory leaks

Jonathan Tan <jonathantanmy@google.com> writes:
Show 15 quoted lines
> A fuzzer running on the entry point provided by fuzz-commit-graph.c
> revealed a memory leak when parse_commit_graph() creates a struct
> bloom_filter_settings and then returns early due to error. Fix that
> error by always freeing that struct first (if it exists) before
> returning early due to error.
>
> While making that change, I also noticed another possible memory leak -
> when the BLOOMDATA chunk is provided but not BLOOMINDEXES. Also fix that
> error.
>
> Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
> ---
> Here's a memory leak fix revealed by a fuzzer running at $DAYJOB, and
> another one that I noticed while making that fix.
> ---
Thanks.  The patch looks good.
Will queue.

← back to recent threads