From: Michael Mueller <hidden> Date: 2016-06-15 22:53:40
Hi all,
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).
Introduced here:
https://github.com/gitster/git/commit/fbc08ea
Best,
Mike
--
Mike Mueller
Phone: (401) 405-1525
Email: mmueller@vigilantsw.com
http://www.vigilantsw.com/
From: Jeff King <hidden> Date: 2016-06-15 22:53:40
On Wed, Apr 25, 2012 at 12:59:28AM -0700, Michael Mueller wrote:
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
From: René Scharfe <hidden> Date: 2016-06-15 22:53:40
Am 25.04.2012 13:14, schrieb Jeff King:
On Wed, Apr 25, 2012 at 12:59:28AM -0700, Michael Mueller wrote:
quoted
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.
More often then not, a mistake like that is surrounded by other issues.
No, I didn't put it there intentionally to prove this point. ;-)
Having to reverse the list at all is unfortunate and I only did that
because I thought appending would be more complicated and because we are
going to replace the linked list with a different data structure soon
anyway. Turns out appending is easy. Patches to follow.
René
From: René Scharfe <hidden> Date: 2016-06-15 22:53:40
This function can be used in other parts of git. Give it a new home
in commit.c.
Signed-off-by: Rene Scharfe <redacted>
---
commit.c | 27 +++++++++++++++++++++++++++
commit.h | 2 ++
sequencer.c | 27 ---------------------------
3 files changed, 29 insertions(+), 27 deletions(-)
From: René Scharfe <hidden> Date: 2016-06-15 22:53:40
By using commit_list_insert(), we added new items to the top of the
list and, since this is not the order we want, reversed it afterwards.
Simplify this process by adding new items at the bottom instead,
getting rid of the reversal step.
Signed-off-by: Rene Scharfe <redacted>
---
revision.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: René Scharfe <hidden> Date: 2016-06-15 22:53:40
The function commit_list_reverse() is not used anymore; delete it.
Signed-off-by: Rene Scharfe <redacted>
---
commit.c | 15 ---------------
commit.h | 1 -
2 files changed, 16 deletions(-)