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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11467 in the body.
You can then email your comments to 11467 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rich Burridge <rich.burridge <at> oracle.com>
To: bug-coreutils <at> gnu.org
Subject: Parfait problems with GNU coreutils
Date: Mon, 14 May 2012 05:25:09 -0700

[Message part 1 (text/plain, inline)]

Hi,

I've been running parfait [1] on GNU coreutils  and it found the following
problems:

Error: Buffer overrun
   Buffer overflow (CWE 120): In array dereference of word_limit[-1] with index '-1'
      Array size is 1000 elements (of 28 bytes each), -1 is -1
        at line 590 of components/coreutils/coreutils-8.5/src/fmt.c in function 'get_paragraph'.
   Read outside array bounds (CWE 125): In array dereference of word_limit[-1] with index '-1'
      Array size is 1000 elements (of 28 bytes each), -1 is -1
        at line 590 of components/coreutils/coreutils-8.5/src/fmt.c in function 'get_paragraph'.
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.
          Null pointer introduced at line 3130 in function 'parse_field_count'.
Error: Null pointer dereference (CWE 476)
   Read from null pointer 'bitsp'
        at line 1546 of components/coreutils/coreutils-8.5/src/stty.c in function 'display_changed'.
          Function 'mode_type_flag' may return constant 'NULL' at line 1453, called at line 1544.
          Null pointer introduced at line 1453 in function 'mode_type_flag'.
Error: Null pointer dereference (CWE 476)
   Read from null pointer 'bitsp'
        at line 1623 of components/coreutils/coreutils-8.5/src/stty.c in function 'display_all'.
          Function 'mode_type_flag' may return constant 'NULL' at line 1453, called at line 1621.
          Null pointer introduced at line 1453 in function 'mode_type_flag'.
Error: Null pointer dereference (CWE 476)
   Read from null pointer 'bitsp'
        at line 1838 of components/coreutils/coreutils-8.5/src/stty.c in function 'sane_mode'.
          Function 'mode_type_flag' may return constant 'NULL' at line 1453, called at line 1837.
          Null pointer introduced at line 1453 in function 'mode_type_flag'.
        at line 1843 of components/coreutils/coreutils-8.5/src/stty.c in function 'sane_mode'.
          Function 'mode_type_flag' may return constant 'NULL' at line 1453, called at line 1842.
          Null pointer introduced at line 1453 in function 'mode_type_flag'.
Error: Null pointer dereference (CWE 476)
   Write to null pointer 'bitsp'
        at line 1838 of components/coreutils/coreutils-8.5/src/stty.c in function 'sane_mode'.
          Function 'mode_type_flag' may return constant 'NULL' at line 1453, called at line 1837.
          Null pointer introduced at line 1453 in function 'mode_type_flag'.
        at line 1843 of components/coreutils/coreutils-8.5/src/stty.c in function 'sane_mode'.
          Function 'mode_type_flag' may return constant 'NULL' at line 1453, called at line 1842.
          Null pointer introduced at line 1453 in function 'mode_type_flag'.



I've attached a patch that we are applying to the code to fix these problems.

Here's the evaluation of why the changes have been made:

There are three different types of Parfait errors here:

1/ In fmt.c, in the get_paragraph() routine, Parfait thinks that there
   is a potential problem of a negative index into the 'word' array.
   But that situation is impossible. Earlier in the routine, get_line()
   is called, and this has to have incremented word_limit. The solution
   was to add a Parfait style comment before the offending line of code
   to shut parfait up.

2/ In sort.c, there is an occurrence in the main() routine where 's' was
   being dereferenced, but it could have been NULL. A check was added
   to only do the dereferencing if that wasn't the case. It was noticed
   that there was already similar code in the same routine, so this seems
   a reasonable solution.

3/ In stty.c, there were two occurrences where bitsp was being dereferenced
   that could have been a NULL pointer. In each case, a check was added
   to only do the dereferencing if that wasn't the case. It was noticed
   that there was already similar code in the sane_mode() routine, so this
   seems a reasonable solution.



These changes make us "parfait clean".

I realize there is a later version of GNU coreutils, but this is the version that currently
ships with Solaris 11. If these problems still exist in the current version, (and assuming
you think these changes are good), hopefully you'll like to make similar changes
in the next version of GNU coreutils.

Thanks.

[1] http://labs.oracle.com/projects/parfait/

[parfait-fix.patch (text/plain, attachment)]

Message #8 received at 11467 <at> debbugs.gnu.org (full text, mbox):

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

Message #11 received at 11467 <at> debbugs.gnu.org (full text, mbox):

From: Rich Burridge <rich.burridge <at> oracle.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 11467 <at> debbugs.gnu.org
Subject: Re: bug#11467: Parfait problems with GNU coreutils
Date: Mon, 14 May 2012 07:02:02 -0700

On 05/14/12 05:43 AM, Jim Meyering wrote:
> 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.

Thanks Jim. Incomplete analysis on my part. This is a(nother) case where
parfait is not smart enough to recognize that error is a non-returning function.

Message #14 received at 11467 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Rich Burridge <rich.burridge <at> oracle.com>
Cc: 11467 <at> debbugs.gnu.org
Subject: Re: bug#11467: Parfait problems with GNU coreutils
Date: Mon, 14 May 2012 16:03:18 +0200

Rich Burridge wrote:
...
> I've attached a patch that we are applying to the code to fix these problems.
>
> Here's the evaluation of why the changes have been made:
>
> There are three different types of Parfait errors here:
>
> 1/ In fmt.c, in the get_paragraph() routine, Parfait thinks that there
>    is a potential problem of a negative index into the 'word' array.
>    But that situation is impossible. Earlier in the routine, get_line()
>    is called, and this has to have incremented word_limit. The solution
>    was to add a Parfait style comment before the offending line of code
>    to shut parfait up.
>
> 2/ In sort.c, there is an occurrence in the main() routine where 's' was
>    being dereferenced, but it could have been NULL. A check was added
>    to only do the dereferencing if that wasn't the case. It was noticed
>    that there was already similar code in the same routine, so this seems
>    a reasonable solution.
>
> 3/ In stty.c, there were two occurrences where bitsp was being dereferenced
>    that could have been a NULL pointer. In each case, a check was added
>    to only do the dereferencing if that wasn't the case. It was noticed
>    that there was already similar code in the sane_mode() routine, so this
>    seems a reasonable solution.

Thanks again.
I've just confirmed that your proposed stty.c change
is not required, since bitsp cannot be NULL when it is
dereferenced.

Are the following proposed changes enough to placate parfait?
I prefer to use assert, because that tends to work also for
static analysis tools like clang and coverity.

From 94f417db5e093093ff9512869880e39975822be8 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering <at> redhat.com>
Date: Mon, 14 May 2012 15:44:41 +0200
Subject: [PATCH] maint: add assertions to placate static analysis tools

A static analysis tool (http://labs.oracle.com/projects/parfait/)
produced some false positive diagnostics.  Add assertions to help
it understand that the code is correct.
* src/stty.c: Include <assert.h>.
(display_changed): Add an assertion to placate parfait.
(display_all): Likewise.
* src/sort.c: Include <assert.h>.
(main): Add an assertion to placate parfait.
---
 src/sort.c | 5 +++++
 src/stty.c | 8 ++++++++
 2 files changed, 13 insertions(+)

diff --git a/src/sort.c b/src/sort.c
index 493e7f1..2593a2a 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -28,6 +28,7 @@
 #include <sys/types.h>
 #include <sys/wait.h>
 #include <signal.h>
+#include <assert.h>
 #include "system.h"
 #include "argmatch.h"
 #include "error.h"
@@ -4243,6 +4244,10 @@ main (int argc, char **argv)
                           char const *optarg1 = argv[optind++];
                           s = parse_field_count (optarg1 + 1, &key->eword,
                                              N_("invalid number after '-'"));
+                          /* When called with a non-NULL message ID,
+                             parse_field_count cannot return NULL.  Tell static
+                             analysis tools that dereferencing S is safe.  */
+                          assert (s);
                           if (*s == '.')
                             s = parse_field_count (s + 1, &key->echar,
                                                N_("invalid number after '.'"));
diff --git a/src/stty.c b/src/stty.c
index eb07f85..a3fc3dd 100644
--- a/src/stty.c
+++ b/src/stty.c
@@ -52,6 +52,7 @@
 #endif
 #include <getopt.h>
 #include <stdarg.h>
+#include <assert.h>

 #include "system.h"
 #include "error.h"
@@ -1538,6 +1539,12 @@ display_changed (struct termios *mode)

       bitsp = mode_type_flag (mode_info[i].type, mode);
       mask = mode_info[i].mask ? mode_info[i].mask : mode_info[i].bits;
+
+      /* bitsp would be NULL only for "combination" modes, yet those
+         are filtered out above via the OMIT flag.  Tell static analysis
+         tools that it's ok to dereference bitsp here.  */
+      assert (bitsp);
+
       if ((*bitsp & mask) == mode_info[i].bits)
         {
           if (mode_info[i].flags & SANE_UNSET)
@@ -1615,6 +1622,7 @@ display_all (struct termios *mode, char const *device_name)

       bitsp = mode_type_flag (mode_info[i].type, mode);
       mask = mode_info[i].mask ? mode_info[i].mask : mode_info[i].bits;
+      assert (bitsp); /* See the identical assertion and comment above.  */
       if ((*bitsp & mask) == mode_info[i].bits)
         wrapf ("%s", mode_info[i].name);
       else if (mode_info[i].flags & REV)
--
1.7.10.2.484.gcd07cc5

Message #17 received at 11467 <at> debbugs.gnu.org (full text, mbox):

From: Rich Burridge <rich.burridge <at> oracle.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 11467 <at> debbugs.gnu.org
Subject: Re: bug#11467: Parfait problems with GNU coreutils
Date: Mon, 14 May 2012 08:40:26 -0700

On 05/14/12 07:03 AM, Jim Meyering wrote:
> ...
> Thanks again.
> I've just confirmed that your proposed stty.c change
> is not required, since bitsp cannot be NULL when it is
> dereferenced.
>
> Are the following proposed changes enough to placate parfait?
> I prefer to use assert, because that tends to work also for
> static analysis tools like clang and coverity.

Yup. These changes work just fine.

Thanks!

>
>  From 94f417db5e093093ff9512869880e39975822be8 Mon Sep 17 00:00:00 2001
> From: Jim Meyering<meyering <at> redhat.com>
> Date: Mon, 14 May 2012 15:44:41 +0200
> Subject: [PATCH] maint: add assertions to placate static analysis tools
>
> A static analysis tool (http://labs.oracle.com/projects/parfait/)
> produced some false positive diagnostics.  Add assertions to help
> it understand that the code is correct.
> * src/stty.c: Include<assert.h>.
> (display_changed): Add an assertion to placate parfait.
> (display_all): Likewise.
> * src/sort.c: Include<assert.h>.
> (main): Add an assertion to placate parfait.
> ---
>   src/sort.c | 5 +++++
>   src/stty.c | 8 ++++++++
>   2 files changed, 13 insertions(+)
>
> diff --git a/src/sort.c b/src/sort.c
> index 493e7f1..2593a2a 100644
> --- a/src/sort.c
> +++ b/src/sort.c
> @@ -28,6 +28,7 @@
>   #include<sys/types.h>
>   #include<sys/wait.h>
>   #include<signal.h>
> +#include<assert.h>
>   #include "system.h"
>   #include "argmatch.h"
>   #include "error.h"
> @@ -4243,6 +4244,10 @@ main (int argc, char **argv)
>                             char const *optarg1 = argv[optind++];
>                             s = parse_field_count (optarg1 + 1,&key->eword,
>                                                N_("invalid number after '-'"));
> +                          /* When called with a non-NULL message ID,
> +                             parse_field_count cannot return NULL.  Tell static
> +                             analysis tools that dereferencing S is safe.  */
> +                          assert (s);
>                             if (*s == '.')
>                               s = parse_field_count (s + 1,&key->echar,
>                                                  N_("invalid number after '.'"));
> diff --git a/src/stty.c b/src/stty.c
> index eb07f85..a3fc3dd 100644
> --- a/src/stty.c
> +++ b/src/stty.c
> @@ -52,6 +52,7 @@
>   #endif
>   #include<getopt.h>
>   #include<stdarg.h>
> +#include<assert.h>
>
>   #include "system.h"
>   #include "error.h"
> @@ -1538,6 +1539,12 @@ display_changed (struct termios *mode)
>
>         bitsp = mode_type_flag (mode_info[i].type, mode);
>         mask = mode_info[i].mask ? mode_info[i].mask : mode_info[i].bits;
> +
> +      /* bitsp would be NULL only for "combination" modes, yet those
> +         are filtered out above via the OMIT flag.  Tell static analysis
> +         tools that it's ok to dereference bitsp here.  */
> +      assert (bitsp);
> +
>         if ((*bitsp&  mask) == mode_info[i].bits)
>           {
>             if (mode_info[i].flags&  SANE_UNSET)
> @@ -1615,6 +1622,7 @@ display_all (struct termios *mode, char const *device_name)
>
>         bitsp = mode_type_flag (mode_info[i].type, mode);
>         mask = mode_info[i].mask ? mode_info[i].mask : mode_info[i].bits;
> +      assert (bitsp); /* See the identical assertion and comment above.  */
>         if ((*bitsp&  mask) == mode_info[i].bits)
>           wrapf ("%s", mode_info[i].name);
>         else if (mode_info[i].flags&  REV)
> --
> 1.7.10.2.484.gcd07cc5

Message #20 received at 11467 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Rich Burridge <rich.burridge <at> oracle.com>
Cc: 11467 <at> debbugs.gnu.org
Subject: Re: bug#11467: Parfait problems with GNU coreutils
Date: Tue, 15 May 2012 22:33:23 +0200

Jim Meyering wrote:

> Rich Burridge wrote:
> ...
>> I've attached a patch that we are applying to the code to fix these problems.
>>
>> Here's the evaluation of why the changes have been made:
>>
>> There are three different types of Parfait errors here:
>>
>> 1/ In fmt.c, in the get_paragraph() routine, Parfait thinks that there
>>    is a potential problem of a negative index into the 'word' array.
>>    But that situation is impossible. Earlier in the routine, get_line()
>>    is called, and this has to have incremented word_limit. The solution
>>    was to add a Parfait style comment before the offending line of code
>>    to shut parfait up.
>>
>> 2/ In sort.c, there is an occurrence in the main() routine where 's' was
>>    being dereferenced, but it could have been NULL. A check was added
>>    to only do the dereferencing if that wasn't the case. It was noticed
>>    that there was already similar code in the same routine, so this seems
>>    a reasonable solution.
>>
>> 3/ In stty.c, there were two occurrences where bitsp was being dereferenced
>>    that could have been a NULL pointer. In each case, a check was added
>>    to only do the dereferencing if that wasn't the case. It was noticed
>>    that there was already similar code in the sane_mode() routine, so this
>>    seems a reasonable solution.
>
> Thanks again.
> I've just confirmed that your proposed stty.c change
> is not required, since bitsp cannot be NULL when it is
> dereferenced.
>
> Are the following proposed changes enough to placate parfait?
> I prefer to use assert, because that tends to work also for
> static analysis tools like clang and coverity.
>
> Subject: [PATCH] maint: add assertions to placate static analysis tools
>
> A static analysis tool (http://labs.oracle.com/projects/parfait/)
> produced some false positive diagnostics.  Add assertions to help
> it understand that the code is correct.
> * src/stty.c: Include <assert.h>.
> (display_changed): Add an assertion to placate parfait.
> (display_all): Likewise.
> * src/sort.c: Include <assert.h>.
> (main): Add an assertion to placate parfait.

Hi Rich,

If you can confirm that the following incremental patch
is enough to inform parfait that there's no real problem
in this part of fmt.c, I'll push the full patch below.

diff --git a/src/fmt.c b/src/fmt.c
index 308b645..e0c04cb 100644
--- a/src/fmt.c
+++ b/src/fmt.c
@@ -20,6 +20,7 @@
 #include <stdio.h>
 #include <sys/types.h>
 #include <getopt.h>
+#include <assert.h>

 /* Redefine.  Otherwise, systems (Unicos for one) with headers that define
    it to be a type get syntax errors for the variable declaration below.  */
@@ -610,6 +611,11 @@ get_paragraph (FILE *f)
       while (same_para (c) && in_column == other_indent)
         c = get_line (f, c);
     }
+
+  /* Tell static analysis tools that word_limit[-1] is ok.
+     word_limit is guaranteed to have been incremented by get_line.  */
+  assert (word < word_limit);
+
   (word_limit - 1)->period = (word_limit - 1)->final = true;
   next_char = c;
   return true;


From 5917d6365e03eee7c28c4add3acf79e9f473d703 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering <at> redhat.com>
Date: Mon, 14 May 2012 15:44:41 +0200
Subject: [PATCH] maint: add assertions to placate static analysis tools

A static analysis tool (http://labs.oracle.com/projects/parfait/)
produced some false positive diagnostics.  Add assertions to help
it understand that the code is correct.
* src/stty.c: Include <assert.h>.
(display_changed): Add an assertion to placate parfait.
(display_all): Likewise.
* src/sort.c: Include <assert.h>.
(main): Add an assertion to placate parfait.
* src/fmt.c: Include <assert.h>.
(get_paragraph): Add an assertion to placate parfait.
---
 src/fmt.c  | 6 ++++++
 src/sort.c | 5 +++++
 src/stty.c | 8 ++++++++
 3 files changed, 19 insertions(+)

diff --git a/src/fmt.c b/src/fmt.c
index 308b645..3da198e 100644
--- a/src/fmt.c
+++ b/src/fmt.c
@@ -20,6 +20,7 @@
 #include <stdio.h>
 #include <sys/types.h>
 #include <getopt.h>
+#include <assert.h>

 /* Redefine.  Otherwise, systems (Unicos for one) with headers that define
    it to be a type get syntax errors for the variable declaration below.  */
@@ -610,6 +611,11 @@ get_paragraph (FILE *f)
       while (same_para (c) && in_column == other_indent)
         c = get_line (f, c);
     }
+
+  /* Tell static analysis tools that using word_limit[-1] is ok.
+     word_limit is guaranteed to have been incremented by get_line.  */
+  assert (word < word_limit);
+
   (word_limit - 1)->period = (word_limit - 1)->final = true;
   next_char = c;
   return true;
diff --git a/src/sort.c b/src/sort.c
index 493e7f1..2593a2a 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -28,6 +28,7 @@
 #include <sys/types.h>
 #include <sys/wait.h>
 #include <signal.h>
+#include <assert.h>
 #include "system.h"
 #include "argmatch.h"
 #include "error.h"
@@ -4243,6 +4244,10 @@ main (int argc, char **argv)
                           char const *optarg1 = argv[optind++];
                           s = parse_field_count (optarg1 + 1, &key->eword,
                                              N_("invalid number after '-'"));
+                          /* When called with a non-NULL message ID,
+                             parse_field_count cannot return NULL.  Tell static
+                             analysis tools that dereferencing S is safe.  */
+                          assert (s);
                           if (*s == '.')
                             s = parse_field_count (s + 1, &key->echar,
                                                N_("invalid number after '.'"));
diff --git a/src/stty.c b/src/stty.c
index eb07f85..a3fc3dd 100644
--- a/src/stty.c
+++ b/src/stty.c
@@ -52,6 +52,7 @@
 #endif
 #include <getopt.h>
 #include <stdarg.h>
+#include <assert.h>

 #include "system.h"
 #include "error.h"
@@ -1538,6 +1539,12 @@ display_changed (struct termios *mode)

       bitsp = mode_type_flag (mode_info[i].type, mode);
       mask = mode_info[i].mask ? mode_info[i].mask : mode_info[i].bits;
+
+      /* bitsp would be NULL only for "combination" modes, yet those
+         are filtered out above via the OMIT flag.  Tell static analysis
+         tools that it's ok to dereference bitsp here.  */
+      assert (bitsp);
+
       if ((*bitsp & mask) == mode_info[i].bits)
         {
           if (mode_info[i].flags & SANE_UNSET)
@@ -1615,6 +1622,7 @@ display_all (struct termios *mode, char const *device_name)

       bitsp = mode_type_flag (mode_info[i].type, mode);
       mask = mode_info[i].mask ? mode_info[i].mask : mode_info[i].bits;
+      assert (bitsp); /* See the identical assertion and comment above.  */
       if ((*bitsp & mask) == mode_info[i].bits)
         wrapf ("%s", mode_info[i].name);
       else if (mode_info[i].flags & REV)
--
1.7.10.2.484.gcd07cc5

Message #23 received at 11467 <at> debbugs.gnu.org (full text, mbox):

From: Rich Burridge <rich.burridge <at> oracle.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 11467 <at> debbugs.gnu.org
Subject: Re: bug#11467: Parfait problems with GNU coreutils
Date: Tue, 15 May 2012 14:04:57 -0700

On 05/15/2012 01:33 PM, Jim Meyering wrote:
> If you can confirm that the following incremental patch is enough to 
> inform parfait that there's no real problem in this part of fmt.c, 
> I'll push the full patch below.

Works great. Thanks for doing this.

Message #26 received at 11467 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Rich Burridge <rich.burridge <at> oracle.com>
Cc: 11467 <at> debbugs.gnu.org
Subject: Re: bug#11467: Parfait problems with GNU coreutils
Date: Sun, 07 Oct 2012 11:54:52 +0200

tags 11467 + notabug
close 11467
thanks

Rich Burridge wrote:
> On 05/14/12 05:43 AM, Jim Meyering wrote:
>> 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.
>
> Thanks Jim. Incomplete analysis on my part. This is a(nother) case where
> parfait is not smart enough to recognize that error is a non-returning function.

This is resolved, so closing.

Previous Next

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