[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11467: Parfait problems with GNU coreutils
From: |
Jim Meyering |
Subject: |
bug#11467: Parfait problems with GNU coreutils |
Date: |
Mon, 14 May 2012 14:43:53 +0200 |
Thanks for auditing coreutils!
A bug in sort would have been a surprise, and more of an issue,
so I've looked at it first.
Rich Burridge wrote:
...
> Error: Null pointer dereference (CWE 476)
> Read from null pointer 's'
> at line 3389 of components/coreutils/coreutils-8.5/src/sort.c in
> function 'main'.
> Function 'parse_field_count' may return constant 'NULL' at line
> 3130, called at line 3387.
That is not true when the third argument to parse_field_count is
non-NULL, as is the case in sort.c from coreutils-8.5 (and in the
latest from git). In that case, parse_field_count exits upon failure
and cannot return NULL.
Here's the comment/header for that function, and the code that
might return NULL:
/* Parse the leading integer in STRING and store the resulting value
(which must fit into size_t) into *VAL. Return the address of the
suffix after the integer. If the value is too large, silently
substitute SIZE_MAX. If MSGID is NULL, return NULL after
failure; otherwise, report MSGID and exit on failure. */
static char const *
parse_field_count (char const *string, size_t *val, char const *msgid)
{
...
case LONGINT_INVALID:
if (msgid)
error (SORT_FAILURE, 0, _("%s: invalid count at start of %s"),
_(msgid), quote (string));
return NULL;
}
sort.c checks "s" after the preceding use of parse_field_count,
because that invocation passes NULL as the third argument, and
hence *can* return NULL.