git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Øystein Walle" <oystwa@gmail.com>
To: gitster@pobox.com
Cc: git@vger.kernel.org, ingy@ingy.net, oystwa@gmail.com,
	szeder.dev@gmail.com
Subject: [PATCH] rev-parse --parseopt: detect missing opt-spec
Date: Fri,  2 Sep 2022 19:59:02 +0200	[thread overview]
Message-ID: <20220902175902.22346-1-oystwa@gmail.com> (raw)
In-Reply-To: <xmqq5yi5aghf.fsf@gitster.g>

After 2d893dff4c (rev-parse --parseopt: allow [*=?!] in argument hints,
2015-07-14) updated the parser, a line in parseopts's input can start
with one of the flag characters and be erroneously parsed as a opt-spec
where the short name of the option is the flag character itself and the
long name is after the end of the string. This makes Git want to
allocate SIZE_MAX bytes of memory at this line:

    o->long_name = xmemdupz(sb.buf + 2, s - sb.buf - 2);

Since s and sb.buf are equal the second argument is -2 (except unsigned)
and xmemdupz allocates len + 1 bytes, ie. -1 meaning SIZE_MAX.

Avoid this by checking whether a flag character was found in the zeroth
position.

Reported-by: Ingy dot Net <ingy@ingy.net>
Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Øystein Walle <oystwa@gmail.com>
---

Hi guys, thanks for the review. I incorporated a reference to the old
commit into the message (and took the liberty of adding --parseopt to
the subject like it had). I tried to verify that it was in fact this
commit, since the code prior to this one had the exact same xmemdupz()
call. I wasn't able to build that commit, and reverting it also wasn't
straightforward. But I'm fairly confident it's the case since the old
call had an if similar to the one added here.

I completely agree with the changes to the test; it makes little sense
to mix stdout and stderr here.

Jeff, I agree that perhaps a larger rewrite would be better. I
personally can get easily confused by "sporadic" ifs like this one in
the middle of a piece of code. At least in this case the message within
die() neatly explains what's going on.

Øsse

 builtin/rev-parse.c           | 3 +++
 t/t1502-rev-parse-parseopt.sh | 7 +++++++
 2 files changed, 10 insertions(+)

diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index b259d8990a..85c271acd7 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -479,6 +479,9 @@ static int cmd_parseopt(int argc, const char **argv, const char *prefix)
 		if (!s)
 			s = help;
 
+		if (s == sb.buf)
+			die(_("missing opt-spec before option flags"));
+
 		if (s - sb.buf == 1) /* short option only */
 			o->short_name = *sb.buf;
 		else if (sb.buf[1] != ',') /* long option only */
diff --git a/t/t1502-rev-parse-parseopt.sh b/t/t1502-rev-parse-parseopt.sh
index 284fe18e72..de1d48f3ba 100755
--- a/t/t1502-rev-parse-parseopt.sh
+++ b/t/t1502-rev-parse-parseopt.sh
@@ -306,6 +306,13 @@ test_expect_success 'test --parseopt help output: "wrapped" options normal "or:"
 	test_cmp expect actual
 '
 
+test_expect_success 'test --parseopt invalid opt-spec' '
+	test_write_lines x -- "=, x" >spec &&
+	echo "fatal: missing opt-spec before option flags" >expect &&
+	test_must_fail git rev-parse --parseopt -- >out <spec 2>err &&
+	test_cmp expect err
+'
+
 test_expect_success 'test --parseopt help output: multi-line blurb after empty line' '
 	sed -e "s/^|//" >spec <<-\EOF &&
 	|cmd [--some-option]
-- 
2.34.1


  reply	other threads:[~2022-09-02 17:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-01 21:15 [BUG] git crashes on simple rev-parse incantation Ingy dot Net
2022-09-02  4:28 ` Øystein Walle
2022-09-02  5:06 ` [PATCH] rev-parse: Detect missing opt-spec Øystein Walle
2022-09-02  5:46   ` Eric Sunshine
2022-09-02  6:39     ` [PATCH v2] " Øystein Walle
2022-09-02  7:15       ` Eric Sunshine
2022-09-02  6:47   ` [PATCH] " SZEDER Gábor
2022-09-02 16:27     ` Junio C Hamano
2022-09-02 17:59       ` Øystein Walle [this message]
2022-09-02 18:01         ` [PATCH] rev-parse --parseopt: detect " Øystein Walle
2022-09-02 18:45           ` Junio C Hamano
2022-09-02 21:00         ` SZEDER Gábor
2022-09-02 21:29           ` Junio C Hamano
2022-09-02 17:13   ` [PATCH] rev-parse: Detect " 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=20220902175902.22346-1-oystwa@gmail.com \
    --to=oystwa@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ingy@ingy.net \
    --cc=szeder.dev@gmail.com \
    /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).