From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Han-Wen Nienhuys <hanwen@google.com>
Cc: git <git@vger.kernel.org>
Subject: Re: Fwd: coverity problems in reftable code
Date: Tue, 07 Dec 2021 18:46:02 +0100 [thread overview]
Message-ID: <211207.86o85snvvv.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <CAFQ2z_OrN+RkwnMyrJHdh5xN6ueOP8KKBVQ7-U4kEkA3ApcuNg@mail.gmail.com>
On Tue, Dec 07 2021, Han-Wen Nienhuys wrote:
> On Sat, Dec 4, 2021 at 3:13 AM Jeff King <peff@peff.net> wrote:
>> We're not doing project-wide analysis with Coverity right now, but I've
>> been doing builds of my personal repo, which I usually build off of
>> next. And since hn/reftable just hit next, it got included in my latest
>> build.
>>
>> It came up with several complaints. Some of them are dumb and can be
>> ignored (e.g., using rand() in a test harness, oh no!) but I poked at a
>> few and they look like real issues:
>
> I fixed most of the obvious ones.
>
>> - A lot of your structs have vtables. Initializing them to NULL, as in
>> reftable_reader_refs_for_indexed(), leaves the risk that we'll try
>> to call a NULL function pointer, even if it's for something simple
>
> I have the impression that coverity doesn't understand enough of the
> control flow. Some of the things it complains of are code paths that
> only get executed if err==0, in which case, the struct members at hand
> should not be null.
I think coverity is right and the code has a logic error as it
suggests.
In the reftable_reader_refs_for_indexed() example Jeff cites we'll "goto
done" on error, and the reftable_record_release(&got_rec) will proceed
to segfault since the next thing we do is to try to dereference a NULL
pointer in reftable_record_release().
You can reproduce that as a segfault in your tests with e.g. this patch
below, which just emulates what would happen if "err != 0":
diff --git a/reftable/reader.c b/reftable/reader.c
index 006709a645a..4c87b75a982 100644
--- a/reftable/reader.c
+++ b/reftable/reader.c
@@ -663,6 +663,7 @@ static int reftable_reader_refs_for_indexed(struct reftable_reader *r,
/* Look through the reverse index. */
reftable_record_from_obj(&want_rec, &want);
err = reader_seek(r, &oit, &want_rec);
+ goto done;
if (err != 0)
goto done;
In that particular case this appears to be the quick fix that's needed:
diff --git a/reftable/record.c b/reftable/record.c
index 6a5dac32dc6..e6594d555e5 100644
--- a/reftable/record.c
+++ b/reftable/record.c
@@ -1090,6 +1090,8 @@ int reftable_record_decode(struct reftable_record *rec, struct strbuf key,
void reftable_record_release(struct reftable_record *rec)
{
+ if (!rec || !rec->ops)
+ return;
rec->ops->release(rec->data);
}
But in general this looks like an excellent candidate for some test
fuzzing, i.e. to intrstrument the various "err" returning functions to
chaos-monkey return non-zero some of the time and check for segfaults.
next prev parent reply other threads:[~2021-12-07 17:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-04 2:13 coverity problems in reftable code Jeff King
[not found] ` <CAFQ2z_OK5949p1WfovJ00Katk5hTv_oeLo-ZRCi1XqrtzQqL2g@mail.gmail.com>
2021-12-07 11:34 ` Fwd: " Han-Wen Nienhuys
2021-12-07 17:46 ` Ævar Arnfjörð Bjarmason [this message]
2021-12-08 1:46 ` Jeff King
2021-12-08 3:26 ` Jeff King
2021-12-08 10:50 ` Han-Wen Nienhuys
2021-12-08 19:12 ` 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=211207.86o85snvvv.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=hanwen@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.