From: Jeff King <peff@peff•net>
To: Junio C Hamano <gitster@pobox•com>
Cc: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail•com>,
Lauri Niskanen <ape@ape3000•com>,
git@vger•kernel.org, Patrick Steinhardt <ps@pks•im>
Subject: Re: [BUG] git stash show -p with invalid option aborts with double-free in show_stash() (strvec_clear)
Date: Fri, 19 Sep 2025 12:48:20 -0400 [thread overview]
Message-ID: <20250919164820.GA24939@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqq4isy77qr.fsf@gitster.g>
On Fri, Sep 19, 2025 at 09:00:12AM -0700, Junio C Hamano wrote:
> The easier, more performant, and closer to the original design
> around the revisions API is to do this:
>
> diff --git c/builtin/stash.c w/builtin/stash.c
> index f5ddee5c7f..b6312b1b70 100644
> --- c/builtin/stash.c
> +++ w/builtin/stash.c
> @@ -1016,6 +1016,8 @@ static int show_stash(int argc, const char **argv, const char *prefix,
> }
>
> argc = setup_revisions(revision_args.nr, revision_args.v, &rev, NULL);
> + for (i = argc; i < revision_args.nr; i++)
> + revision_args.v[i] = NULL;
> if (argc > 1)
> goto usage;
> if (!rev.diffopt.output_format) {
I think we'll have leaked the string holding "-p" in this instance,
though. We probably need to pass in a setup_revision_opt struct with its
free_removed_argv_elements flag set.
That's true even without your patch, too, of course. I'm mildly
surprised that the test suite doesn't hit this in leak-checking mode,
since it is a problem any time we rearrange argv. E.g., I think:
git stash show -p --
leaks (I was surprised that "stash show -p --stat" didn't leak, but it
doesn't seem to rearrange?).
Another interesting thing about your patch above is that it fills the
strvec with a bunch of NULL entries. Which happens to work, because
free(NULL) is a noop, but I think may be subtly violating assumptions
made about strvecs. Probably:
revision_args.nr = setup_revisions(...);
fits my mental model better, though that is violating a different strvec
invariant now (that the .v[.nr] is always NULL). I think
setup_revisions() is a little sloppy not to set argv[argc] to NULL
itself.
> A less performant but may in the longer term safer alternative is to
> change the caller-callee contract around setup_revisions() so that
> the later "unused" slots in the argv array is NULLed before
> returning to the caller, i.e. instead of leaving
>
> .v = { "show", "--no-such-option", "--no-such-option", NULL }
>
> in the revision_args.v[] array, teach setup_revisions() to leave
>
> .v = { "show", "--no-such-option", NULL, NULL }
>
> there (again, we cannot do anything about .nr that is only available
> to the caller).
I think we should consider a fix like this. Grepping for the
free_removed_argv_elements option, there are a few other spots that
correctly use that flag, but aren't updating the strvec argc. E.g.,
bisect_rev_setup(). So they're going to run into the same problem.
I wonder if the best solution is a setup_revisions() wrapper for strvecs
that will:
- turn on the free_removed_argv_elements option automatically
- collect the return value of setup_revisions() and use it to fix
the .nr field of the strvec
- restore the NULL invariant at the end of the array (though I would
also be happy if setup_revisions() just did this itself)
-Peff
next prev parent reply other threads:[~2025-09-19 16:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-19 10:18 [BUG] git stash show -p with invalid option aborts with double-free in show_stash() (strvec_clear) Lauri Niskanen
2025-09-19 13:11 ` Kristoffer Haugsbakk
2025-09-19 16:00 ` Junio C Hamano
2025-09-19 16:48 ` Jeff King [this message]
2025-09-19 17:13 ` Junio C Hamano
2025-09-19 16:58 ` Junio C Hamano
2025-09-19 17:20 ` Jeff King
2025-09-19 18:15 ` Junio C Hamano
2025-09-19 19:56 ` Jeff King
2025-09-19 22:33 ` [PATCH 0/6] fixing double-frees and leaks via setup_revisions() Jeff King
2025-09-19 22:40 ` [PATCH 1/6] stash: tell setup_revisions() to free our allocated strings Jeff King
2025-09-22 15:45 ` Junio C Hamano
2025-09-22 19:05 ` Jeff King
2025-09-22 19:36 ` Junio C Hamano
2025-09-22 20:25 ` Jeff King
2025-09-22 21:26 ` Junio C Hamano
2025-09-23 0:48 ` Jeff King
2025-09-19 22:45 ` [PATCH 2/6] revision: manage memory ownership of argv in setup_revisions() Jeff King
2025-09-19 22:48 ` [PATCH 3/6] revision: add wrapper to setup_revisions() from a strvec Jeff King
2025-09-20 5:10 ` Eric Sunshine
2025-09-20 5:48 ` Jeff King
2025-09-19 22:49 ` [PATCH 4/6] treewide: use setup_revisions_from_strvec() when we have " Jeff King
2025-09-19 22:50 ` [PATCH 5/6] treewide: pass strvecs around for setup_revisions_from_strvec() Jeff King
2025-09-19 23:11 ` Jeff King
2025-09-19 22:51 ` [PATCH 6/6] revision: retain argv NULL invariant in setup_revisions() Jeff King
2025-09-19 23:07 ` Jeff King
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=20250919164820.GA24939@coredump.intra.peff.net \
--to=peff@peff$(echo .)net \
--cc=ape@ape3000$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=kristofferhaugsbakk@fastmail$(echo .)com \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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