From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Kirill Smelkov" <kirr@nexedi.com>,
git@vger.kernel.org, "Jonathan Tan" <jonathantanmy@google.com>,
"Alain Takoudjou" <alain.takoudjou@nexedi.com>,
"Jérome Perrin" <jerome@nexedi.com>
Subject: Re: [PATCH] fetch-pack: fix segfault when fscking without --lock-pack
Date: Thu, 20 Jun 2024 10:57:33 -0700 [thread overview]
Message-ID: <xmqq4j9nwl82.fsf@gitster.g> (raw)
In-Reply-To: <20240619130256.GA228005@coredump.intra.peff.net> (Jeff King's message of "Wed, 19 Jun 2024 09:02:56 -0400")
Jeff King <peff@peff.net> writes:
> Before that commit, if pack_lockfiles was NULL, we wouldn't bother
> reading the output from index-pack at all. But since that commit,
> index-pack may produce extra output if we asked it to fsck. So even if
> nobody cares about the lockfile path, we still need to read it to skip
> to the output we do care about.
True. Looking at that problematic commit, I wonder how it passed
the review process. As a design, adding a list of bare object IDs
without marking what they are for is way too inextensible by our
standard practice.
It is probably not too late to fix it, as this is purely an internal
implementation detail between fetch-pack and index-pack that is not
even documented ("git index-pack --help" does talk about the
"(pack|keep)\t<pack-name>" output, but never the output after that).
> We correctly check that we didn't get a NULL lockfile path (which can
> happen if we did not ask it to create a .keep file at all), but we
> missed the case where the lockfile path is not NULL (due to "-k -k") but
> the pack_lockfiles string_list is NULL (because nobody passed
> "--lock-pack"), and segfault trying to add to the NULL string-list.
>
> We can fix this by skipping the append to the string list when either
> the value or the list is NULL. In that case we must also free the
> lockfile path to avoid leaking it when it's non-NULL.
OK.
> diff --git a/fetch-pack.c b/fetch-pack.c
> index eba9e420ea..42f48fbc31 100644
> --- a/fetch-pack.c
> +++ b/fetch-pack.c
> @@ -1038,8 +1038,10 @@ static int get_pack(struct fetch_pack_args *args,
>
> if (!is_well_formed)
> die(_("fetch-pack: invalid index-pack output"));
> - if (pack_lockfile)
> + if (pack_lockfiles && pack_lockfile)
> string_list_append_nodup(pack_lockfiles, pack_lockfile);
> + else
> + free(pack_lockfile);
> parse_gitmodules_oids(cmd.out, gitmodules_oids);
> close(cmd.out);
> }
That looks like a very safe thing to do.
> diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
> index b26f367620..585ea0ee16 100755
> --- a/t/t5500-fetch-pack.sh
> +++ b/t/t5500-fetch-pack.sh
> @@ -993,6 +993,16 @@ test_expect_success 'ensure bogus fetch.negotiationAlgorithm yields error' '
> fetch origin server_has both_have_2
> '
>
> +test_expect_success 'fetch-pack with fsckObjects and keep-file does not segfault' '
> + rm -rf server client &&
> + test_create_repo server &&
> + test_commit -C server one &&
> +
> + test_create_repo client &&
> + git -c fetch.fsckObjects=true \
> + -C client fetch-pack -k -k ../server HEAD
> +'
> +
And the test is quite straight-forward.
Will queue. Thanks.
prev parent reply other threads:[~2024-06-20 17:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-06 13:36 [PATCH] fetch-pack: test: demonstrate segmentation fault when run with fsckObjects but without --lock-pack Kirill Smelkov
2024-06-19 5:14 ` [RESEND, BUG, SIGSEGV CRASH] (Re: [PATCH] fetch-pack: test: demonstrate segmentation fault when run with fsckObjects but without --lock-pack) Kirill Smelkov
2024-06-19 13:02 ` [PATCH] fetch-pack: fix segfault when fscking without --lock-pack Jeff King
2024-06-19 13:22 ` Jeff King
2024-06-19 13:35 ` Jeff King
2024-06-19 19:39 ` Kirill Smelkov
2024-06-20 17:57 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq4j9nwl82.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=alain.takoudjou@nexedi.com \
--cc=git@vger.kernel.org \
--cc=jerome@nexedi.com \
--cc=jonathantanmy@google.com \
--cc=kirr@nexedi.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).