From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: Matthew Hughes <matthewhughes934@gmail.com>,
git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] grep: report missing left operand of --and
Date: Tue, 29 Jun 2021 19:52:19 +0200 [thread overview]
Message-ID: <87im1wft42.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <98171911-ba39-27f1-d068-4d381bcd4804@web.de>
On Mon, Jun 28 2021, René Scharfe wrote:
> Git grep allows combining two patterns with --and. It checks and
> reports if the second pattern is missing when compiling the expression.
> A missing first pattern, however, is only reported later at match time.
> Thus no error is returned if no matching is done, e.g. because no file
> matches the also given pathspec.
>
> When that happens we get an expression tree with an GREP_NODE_AND node
> and a NULL pointer to the missing left child. free_pattern_expr()
> tries to dereference it during the cleanup at the end, which result in
> a segmentation fault.
>
> Fix this by verifying the presence of the left operand at expression
> compilation time.
>
> Reported-by: Matthew Hughes <matthewhughes934@gmail.com>
> Signed-off-by: René Scharfe <l.s.r@web.de>
> ---
> Whether the check in match_expr_eval() can now be turned into a BUG is
> left as an exercise for the reader. ;-)
>
> grep.c | 2 ++
> t/t7810-grep.sh | 10 ++++++++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/grep.c b/grep.c
> index 8f91af1cb0..7d0ea4e956 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -655,6 +655,8 @@ static struct grep_expr *compile_pattern_and(struct grep_pat **list)
> struct grep_expr *x, *y, *z;
>
> x = compile_pattern_not(list);
> + if (!x)
> + die("Not a valid grep expression");
> p = *list;
> if (p && p->token == GREP_AND) {
> if (!p->next)
> diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
> index 5830733f3d..c581239674 100755
> --- a/t/t7810-grep.sh
> +++ b/t/t7810-grep.sh
> @@ -11,6 +11,13 @@ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
>
> . ./test-lib.sh
>
> +test_invalid_grep_expression() {
> + params="$@" &&
> + test_expect_success "invalid expression: grep $params" '
> + test_must_fail git grep $params -- nonexisting
> + '
> +}
> +
> cat >hello.c <<EOF
> #include <assert.h>
> #include <stdio.h>
> @@ -89,6 +96,9 @@ test_expect_success 'grep should not segfault with a bad input' '
> test_must_fail git grep "("
> '
>
> +test_invalid_grep_expression -e A --and
> +test_invalid_grep_expression --and -e A
> +
> for H in HEAD ''
> do
> case "$H" in
This seems like an incomplete fix, for the exact same thing with --or we
silently return 1, as we would if we exited early in free_pattern_expr
on !x, which aside from the segfault I think we should probably make a
habit in our own free()-like functions.
Whatever we're doing about the --and segfault it seems like we should do
the same under --or, no?
Your first test also passes before your fix, it's only the latter that
segfaults. The first one emits:
fatal: --and not followed by pattern expression
So having that in a leading patch to indicate no behavior was changed
would be better.
Instead of the "Not a valid grep expression" error let's instead say
something like:
fatal: --[and|or] must follow a pattern expression
The error (which I know you just copied from elsewhere) is misleading,
it's not the pattern that's not valid (as to me it implies), but our own
--and/--or option usage.
And the "excercise for the reader" is a bit flippant, do we actually hit
that condition now? If not and we're sure we won't now seems like the
time to add a BUG() there, and to change the "Not a valid grep
expression" to "internal error in --and/--or parsing" or something.
Thanks for the patch!
next prev parent reply other threads:[~2021-06-29 18:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-28 12:17 segfault on invalid 'git grep' invocation Matthew Hughes
2021-06-28 18:53 ` Ævar Arnfjörð Bjarmason
2021-06-28 18:58 ` [PATCH] grep: report missing left operand of --and René Scharfe
2021-06-29 17:52 ` Ævar Arnfjörð Bjarmason [this message]
2021-06-29 18:35 ` René Scharfe
2021-06-30 16:12 ` [PATCH v2] " René Scharfe
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87im1wft42.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=l.s.r@web.de \
--cc=matthewhughes934@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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).