Re: Possible segfault introduced in commit.c

From: Jeff King <peff@peff.net>
Date: Apr 25, 2012, 11:14 UTC
Message-ID: <20120425111435.GA21579@sigill.intra.peff.net>
In-Reply-To: <CANV9Rr_ev+34Wd030cps0UbgjRYD0=L2DQhbrCOkBVWG-2xaug@mail.gmail.com>

On Wed, Apr 25, 2012 at 12:59:28AM -0700, Michael Mueller wrote:

Show 17 quoted lines

> As you might already know, we analyze git regularly with Sentry (our
> static analysis tool).  Today it picked up a new NULL pointer
> dereference in commit.c:366:
> 
>     void commit_list_reverse(struct commit_list **list_p)
>     {
>         struct commit_list *prev = NULL, *curr = *list_p, *next;
> 
>         if (!list_p)
>             return;
>         /* function continues... */
>     }
> 
> list_p is dereferenced on the first line, then tested for NULL on
> the very next statement.  If it's possible that list_p is NULL, this
> will be a segfault.  If it can't be NULL, then the check is
> unnecessary (and probably misleading).

Yes, you're right. There is only one caller currently, and it can never be NULL (it passes the address-of a pointer variable). I think dropping the NULL-check is the right thing; even an empty list will still have a pointer to its NULL head.

-Peff