This is the mail archive of the
mailing list for the glibc project.
[Bug glob/22320] New: Heap buffer overflow in glob
- From: "tim.ruehsen at gmx dot de" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 19 Oct 2017 14:36:57 +0000
- Subject: [Bug glob/22320] New: Heap buffer overflow in glob
- Auto-submitted: auto-generated
Bug ID: 22320
Summary: Heap buffer overflow in 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
@@ -764,7 +764,7 @@ glob (const char *pattern, int flags, int (*errfunc) (const
char *, int),
*p = '\0';
- *((char *) mempcpy (newp, dirname + 1, end_name - dirname))
+ *((char *) mempcpy (newp, dirname + 1, end_name - dirname -
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))
memcpy (newp, dirname + 1, end_name - dirname);
newp[end_name - dirname - 1] = '\0';
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.