From: Darren Kenny <darren.kenny@oracle.com>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Daniel Kiper <daniel.kiper@oracle.com>, bug-gnulib@gnu.org
Subject: Re: [PATCH 1/3] lib/regexec: Fix possible null-dereference
Date: Mon, 23 Aug 2021 11:05:13 +0100 [thread overview]
Message-ID: <m2bl5ojx2e.fsf@oracle.com> (raw)
In-Reply-To: <bc9d25c9-c4b9-d22d-5f9e-be17e9d5dc0a@cs.ucla.edu>
Hi Paul,
Sorry, somehow I missed your responses.
On Wednesday, 2021-08-11 at 00:28:26 -07, Paul Eggert wrote:
> On 6/18/21 8:44 AM, Darren Kenny wrote:
>> It appears to be possible that the mctx->state_log field may be NULL
>
> How so? I don't see the execution path that would do that.
>
The explanation given by Coverity boils down to:
- In check_matching(), line 1069, there is a test if mctx->state_log !=
NULL
- Later there is a call to transit_state() at line 1125, which is
followed by a check for mctx->state_log != NULL again.
- In transit_state(), there is a call to transit_state_mb() at line
2226, which in turn, at line 2497, directly references mctx->state_log
without first checking if it is NULL.
Because of the existing checks if mctx->state_log != NULL, Coverity
seems to be assuming that it is possible that it may be NULL, so
transit_state_mb()'s use of it should also be checking it.
Coverity also acknowledges that extend_buffers() may also modify the
field, but not in all cases.
> If you can see how it could happen, please let us know. Otherwise, does
> the attached patch pacify Coverity, and if not why not?
>
The patch we have already satisfies Coverity, once applied, I have not
checked if a DEBUG_ASSERT() call, in a path that Coverity isn't
including anywhere in its analysis would work.
Why do you think an assert in clean_state_log_if_needed() would help?
Thanks,
Darren.
> The DEBUG_ASSERT stuff does pacify GCC, as it tells GCC things that GCC
> isn't smart enough to figure out on its own. I hope Coverity can use
> similar advice.
> diff --git a/lib/regexec.c b/lib/regexec.c
> index 5e4eb497a..f25e00d83 100644
> --- a/lib/regexec.c
> +++ b/lib/regexec.c
> @@ -1674,6 +1674,8 @@ build_sifted_states (const re_match_context_t *mctx, re_sift_context_t *sctx,
> static reg_errcode_t
> clean_state_log_if_needed (re_match_context_t *mctx, Idx next_state_log_idx)
> {
> + DEBUG_ASSERT (mctx->state_log != NULL);
> +
> Idx top = mctx->state_log_top;
>
> if ((next_state_log_idx >= mctx->input.bufs_len
next prev parent reply other threads:[~2021-08-23 10:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-18 15:44 [PATCH 0/3] Some Coverity fixes from GRUB Darren Kenny
2021-06-18 15:44 ` [PATCH 1/3] lib/regexec: Fix possible null-dereference Darren Kenny
2021-08-11 7:28 ` Paul Eggert
2021-08-23 10:05 ` Darren Kenny [this message]
2021-08-23 20:09 ` Paul Eggert
2021-08-24 15:11 ` Darren Kenny
2021-08-24 18:52 ` Paul Eggert
2021-06-18 15:44 ` [PATCH 2/3] lib/argp-help: Fix possible dereference of a NULL state Darren Kenny
2021-06-18 17:36 ` Bruno Haible
2021-06-21 9:32 ` Darren Kenny
2021-06-18 15:44 ` [PATCH 3/3] lib/regexec: Resolve unused variable Darren Kenny
2021-08-11 7:24 ` Paul Eggert
2021-08-23 10:38 ` Darren Kenny
2021-08-23 13:00 ` Bruno Haible
2021-08-23 21:04 ` Paul Eggert
2021-08-06 14:29 ` [PATCH 0/3] Some Coverity fixes from GRUB Darren Kenny
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: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2bl5ojx2e.fsf@oracle.com \
--to=darren.kenny@oracle.com \
--cc=bug-gnulib@gnu.org \
--cc=daniel.kiper@oracle.com \
--cc=eggert@cs.ucla.edu \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).