diff mbox series

[2/2] upload-pack.c: don't free allowed_filters util pointers

Message ID a3c721054f337eac2b3a038e51693f44b68dd619.1607021483.git.me@ttaylorr.com (mailing list archive)
State Accepted
Commit 8d133f500a5390a089988141cdec8154a732764d
Headers show
Series upload-pack.c: fix partial clone allowed filter regression | expand

Commit Message

Taylor Blau Dec. 3, 2020, 6:55 p.m. UTC
To keep track of which object filters are allowed or not, 'git
upload-pack' stores the name of each filter in a string_list, and sets
it ->util pointer to be either 0 or 1, indicating whether it is banned
or allowed.

Later on, we attempt to clear that list, but we incorrectly ask for the
util pointers to be free()'d, too. This behavior (introduced back in
6dd3456a8c (upload-pack.c: allow banning certain object filter(s),
2020-08-03)) leads to an invalid free, and causes us to crash.

In order to trigger this, one needs to fetch from a server that (a) has
at least one object filter allowed, and (b) issue a fetch that contains
a subset of the allowed filters (i.e., we cannot ask for a banned
filter, since this causes us to die() before we hit the bogus
string_list_clear()).

In that case, whatever banned filters exist will cause a noop free()
(since those ->util pointers are set to 0), but the first allowed filter
we try to free will crash us.

We never noticed this in the tests because we didn't have an example of
setting 'uploadPackFilter' configuration variables and then following up
with a valid fetch. The first new 'git clone' prevents further
regression here. For good measure on top, add a test which checks the
same behavior at a tree depth greater than 0.

Signed-off-by: Taylor Blau <me@ttaylorr.com>
---
 t/t5616-partial-clone.sh | 10 +++++++++-
 upload-pack.c            |  2 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

Comments

Jeff King Dec. 4, 2020, 9:04 p.m. UTC | #1
On Thu, Dec 03, 2020 at 01:55:18PM -0500, Taylor Blau wrote:

> We never noticed this in the tests because we didn't have an example of
> setting 'uploadPackFilter' configuration variables and then following up
> with a valid fetch. The first new 'git clone' prevents further
> regression here. For good measure on top, add a test which checks the
> same behavior at a tree depth greater than 0.

Very nice. The fix is obviously the right thing, but I like the
improvements to the tests here especially.

-Peff
diff mbox series

Patch

diff --git a/t/t5616-partial-clone.sh b/t/t5616-partial-clone.sh
index f4d49d8335..5da945cf15 100755
--- a/t/t5616-partial-clone.sh
+++ b/t/t5616-partial-clone.sh
@@ -281,7 +281,15 @@  test_expect_success 'upload-pack limits tree depth filters' '
 	test_config -C srv.bare uploadpackfilter.tree.maxDepth 0 &&
 	test_must_fail ok=sigpipe git clone --no-checkout --filter=tree:1 \
 		"file://$(pwd)/srv.bare" pc3 2>err &&
-	test_i18ngrep "tree filter allows max depth 0, but got 1" err
+	test_i18ngrep "tree filter allows max depth 0, but got 1" err &&
+
+	git clone --no-checkout --filter=tree:0 "file://$(pwd)/srv.bare" pc4 &&
+
+	test_config -C srv.bare uploadpackfilter.tree.maxDepth 5 &&
+	git clone --no-checkout --filter=tree:5 "file://$(pwd)/srv.bare" pc5 &&
+	test_must_fail ok=sigpipe git clone --no-checkout --filter=tree:6 \
+		"file://$(pwd)/srv.bare" pc6 2>err &&
+	test_i18ngrep "tree filter allows max depth 5, but got 6" err
 '
 
 test_expect_success 'partial clone fetches blobs pointed to by refs even if normally filtered out' '
diff --git a/upload-pack.c b/upload-pack.c
index 5dc8e1f844..d89c7e4a02 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -154,7 +154,7 @@  static void upload_pack_data_clear(struct upload_pack_data *data)
 	string_list_clear(&data->deepen_not, 0);
 	object_array_clear(&data->extra_edge_obj);
 	list_objects_filter_release(&data->filter_options);
-	string_list_clear(&data->allowed_filters, 1);
+	string_list_clear(&data->allowed_filters, 0);
 
 	free((char *)data->pack_objects_hook);
 }