bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
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


  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).