GNU bug report logs - #11467
Parfait problems with GNU coreutils

Previous Next

Full log

View this message in rfc822 format

From: Jim Meyering <jim <at> meyering.net>
To: Rich Burridge <rich.burridge <at> oracle.com>
Cc: 11467 <at> debbugs.gnu.org
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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.