From: Junio C Hamano <gitster@pobox.com>
To: Stefan Naewe <stefan.naewe@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] revision.c: fix possible null pointer access
Date: Thu, 03 Dec 2015 12:06:52 -0800 [thread overview]
Message-ID: <xmqqlh9bthyb.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <1449171136-31566-1-git-send-email-stefan.naewe@gmail.com> (Stefan Naewe's message of "Thu, 3 Dec 2015 20:32:16 +0100")
Stefan Naewe <stefan.naewe@gmail.com> writes:
> Two functions dereference a tree pointer before checking
Reading them a bit carefully, a reader would notice that they
actually do not dereference the pointer at all. It just computes
another pointer and that is done by adding the offset of object
member in the tree struct.
> if the pointer is valid. Fix that by doing the check first.
>
> Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
> ---
> This has been reported through the CppHints newsletter (http://cpphints.com/hints/40)
> but doesn't seem to have made its way to the ones who care (the git list
> that is...)
Nobody would be surprised, unless the newsletter was sent to this
list, which I do not think it was (but if it was sent while I was
away, then it is very possible that I didn't see it).
> revision.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/revision.c b/revision.c
> index 0fbb684..bb40179 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -104,7 +104,12 @@ static void mark_tree_contents_uninteresting(struct tree *tree)
> {
> struct tree_desc desc;
> struct name_entry entry;
> - struct object *obj = &tree->object;
> + struct object *obj;
> +
> + if (!tree)
> + return;
> +
> + obj = &tree->object;
This is questionable; if you check all the callers of this function
(there are two of them, I think), you would notice that they both
know that tree cannot be NULL here.
>
> if (!has_sha1_file(obj->sha1))
> return;
> @@ -135,10 +140,13 @@ static void mark_tree_contents_uninteresting(struct tree *tree)
>
> void mark_tree_uninteresting(struct tree *tree)
> {
> - struct object *obj = &tree->object;
> + struct object *obj;
>
> if (!tree)
> return;
> +
> + obj = &tree->object;
> +
> if (obj->flags & UNINTERESTING)
> return;
This one is not wrong per-se, but an unnecessary change, because no
deferencing is involved. At least, please lose the blank line after
the new assignment.
> obj->flags |= UNINTERESTING;
Thanks.
next prev parent reply other threads:[~2015-12-03 20:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-03 19:32 [PATCH] revision.c: fix possible null pointer access Stefan Naewe
2015-12-03 20:06 ` Junio C Hamano [this message]
2015-12-03 21:15 ` Stefan Naewe
2015-12-03 21:34 ` Philip Oakley
2015-12-03 22:17 ` Stefan Beller
2015-12-04 15:39 ` Junio C Hamano
2015-12-04 23:32 ` Jeff King
2015-12-05 15:27 ` [PATCH v2] " Stefan Naewe
2015-12-07 20:31 ` Junio C Hamano
2015-12-07 21:54 ` Johannes Sixt
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=xmqqlh9bthyb.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=stefan.naewe@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 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.