[Bug glob/22320] New: Heap buffer overflow in glob

["tim.ruehsen at gmx dot de" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=22320

            Bug ID: 22320
           Summary: Heap buffer overflow in glob
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: glob
          Assignee: unassigned at sourceware dot org
          Reporter: tim.ruehsen at gmx dot de
  Target Milestone: ---

Sorry, couldn't find any glibc security policy...

Gnulib's glob(), which is a copy of glibc's glob() seems to have a buffer
overflow. Clangs' address sanitizer reports a WRITE overflow, gcc's reports a
READ overflow when using the same sanitizer options.

Here is a patch and some comments from Bruno Haible (gnulib maintainer), who
tracked it down:

This patch fixes both problems.

diff --git a/lib/glob.c b/lib/glob.c
index 33030ec..6753043 100644
--- a/lib/glob.c
+++ b/lib/glob.c
@@ -764,7 +764,7 @@ glob (const char *pattern, int flags, int (*errfunc) (const
char *, int),
                   *p = '\0';
                 }
               else
-                *((char *) mempcpy (newp, dirname + 1, end_name - dirname))
+                *((char *) mempcpy (newp, dirname + 1, end_name - dirname -
1))
                   = '\0';
               user_name = newp;
             }

The bug also exists in glibc, at least since 2005-12-14. Interestingly, this
mempcpy call was originally

# ifdef HAVE_MEMPCPY
              *((char *) mempcpy (newp, dirname + 1, end_name - dirname))
                = '\0';
# else
              memcpy (newp, dirname + 1, end_name - dirname);
              newp[end_name - dirname - 1] = '\0';
# endif

and the code in the #else branch was correct.


I have a reproducer C code plus a data file, let me know if you are interested
(the 'Add an Attachment' just allows one file).

-- 
You are receiving this mail because:
You are on the CC list for the bug.