]> git.ipfire.org Git - thirdparty/git.git/commit - transport.c
transport: deep-copy object-filter struct for fetch-pack
authorJeff King <peff@peff.net>
Thu, 8 Sep 2022 04:57:29 +0000 (00:57 -0400)
committerJunio C Hamano <gitster@pobox.com>
Thu, 8 Sep 2022 18:06:14 +0000 (11:06 -0700)
commit3f0e86a158e85de20537e8b2c8531d09802433ba
tree27b6945f7f1d494579947173e521c47ba974acd3
parent3fbfbbb7e3c21515a2863702734fe31bf50672fd
transport: deep-copy object-filter struct for fetch-pack

When the transport code for the git protocol calls into fetch_pack(), it
has to fill out a fetch_pack_args struct that is mostly taken from the
transport options. We pass along any object-filter data by doing a
struct assignment of the list_objects_filter_options struct. But doing
so isn't safe; it contains allocated pointers in its filter_spec
string_list, which could lead to a double-free if one side mutates or
frees the string_list.

And indeed, the fetch-pack code does clear and rewrite the list via
expand_list_objects_filter_spec(), leaving the transport code with
dangling pointers.

This hasn't been a problem so far, though, because the transport code
doesn't look further at the filter struct. But it should, because in
some cases (when fetch-pack doesn't rewrite the list), it ends up
leaking the string_list.

So let's start by turning this shallow copy into a deep one, which
should let us fix the transport leak in a subsequent patch. Likewise,
we'll free the deep copy we made here when we're done with it (to avoid
leaking).

Note that it would also work to pass fetch-pack a pointer to our filter
struct, rather than a copy. But it's awkward for fetch-pack to take a
pointer in its arg struct; the actual git-fetch-pack command allocates a
fetch_pack_args struct on the stack and expects it to contain the filter
options. It could be rewritten to avoid this, but a deep copy serves our
purposes just as well.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
transport.c