public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/16976] New: fnmatch unbounded stack VLA for collating symbols
@ 2014-05-22 21:30 jsm28 at gcc dot gnu.org
2014-05-22 21:44 ` [Bug libc/16976] " joseph at codesourcery dot com
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2014-05-22 21:30 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16976
Bug ID: 16976
Summary: fnmatch unbounded stack VLA for collating symbols
Product: glibc
Version: 2.19
Status: NEW
Severity: normal
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: jsm28 at gcc dot gnu.org
CC: drepper.fsp at gmail dot com
When fnmatch is called in a multibyte locale it converts the strings internally
to wide characters (see bug 14185 for ways in which this is suboptimal). If
the pattern contains collating symbols ([.collating-element.] inside []) then
an unbounded VLA is used to convert the collating symbol name back to narrow
characters. Consider the following test (which segfaults for me):
#include <fnmatch.h>
#include <locale.h>
#include <stdio.h>
#include <string.h>
#define LENGTH 20000000
char pattern[LENGTH + 7];
int
main (void)
{
if (setlocale (LC_ALL, "en_US.UTF-8") == NULL)
{
puts ("could not set locale");
return 1;
}
pattern[0] = '[';
pattern[1] = '[';
pattern[2] = '.';
memset (pattern + 3, 'a', LENGTH);
pattern[LENGTH + 3] = '.';
pattern[LENGTH + 4] = ']';
pattern[LENGTH + 5] = ']';
int ret = fnmatch (pattern, "a", 0);
if (ret == 0)
{
puts ("fnmatch returned 0 for invalid pattern");
return 1;
}
return 0;
}
I'm not aware of any limit on the length of valid collating element names, so I
suppose fnmatch should deal with long names in some sensible way rather than
automatically treating them as errors.
Given previous CVEs for fnmatch stack overflows I suppose this may merit a CVE
as well.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libc/16976] fnmatch unbounded stack VLA for collating symbols
2014-05-22 21:30 [Bug libc/16976] New: fnmatch unbounded stack VLA for collating symbols jsm28 at gcc dot gnu.org
@ 2014-05-22 21:44 ` joseph at codesourcery dot com
2014-05-28 14:21 ` fweimer at redhat dot com
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: joseph at codesourcery dot com @ 2014-05-22 21:44 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16976
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Note that there are two copies in fnmatch of the problematic code
involving "char str[c1];", I think in order to handle ranges. Both copies
will need fixing.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libc/16976] fnmatch unbounded stack VLA for collating symbols
2014-05-22 21:30 [Bug libc/16976] New: fnmatch unbounded stack VLA for collating symbols jsm28 at gcc dot gnu.org
2014-05-22 21:44 ` [Bug libc/16976] " joseph at codesourcery dot com
@ 2014-05-28 14:21 ` fweimer at redhat dot com
2014-06-12 19:08 ` fweimer at redhat dot com
2015-08-27 22:22 ` [Bug glob/16976] " jsm28 at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: fweimer at redhat dot com @ 2014-05-28 14:21 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16976
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fweimer at redhat dot com
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libc/16976] fnmatch unbounded stack VLA for collating symbols
2014-05-22 21:30 [Bug libc/16976] New: fnmatch unbounded stack VLA for collating symbols jsm28 at gcc dot gnu.org
2014-05-22 21:44 ` [Bug libc/16976] " joseph at codesourcery dot com
2014-05-28 14:21 ` fweimer at redhat dot com
@ 2014-06-12 19:08 ` fweimer at redhat dot com
2015-08-27 22:22 ` [Bug glob/16976] " jsm28 at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: fweimer at redhat dot com @ 2014-06-12 19:08 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16976
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |security+
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug glob/16976] fnmatch unbounded stack VLA for collating symbols
2014-05-22 21:30 [Bug libc/16976] New: fnmatch unbounded stack VLA for collating symbols jsm28 at gcc dot gnu.org
` (2 preceding siblings ...)
2014-06-12 19:08 ` fweimer at redhat dot com
@ 2015-08-27 22:22 ` jsm28 at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2015-08-27 22:22 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16976
Joseph Myers <jsm28 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|libc |glob
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-08-27 22:22 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-22 21:30 [Bug libc/16976] New: fnmatch unbounded stack VLA for collating symbols jsm28 at gcc dot gnu.org
2014-05-22 21:44 ` [Bug libc/16976] " joseph at codesourcery dot com
2014-05-28 14:21 ` fweimer at redhat dot com
2014-06-12 19:08 ` fweimer at redhat dot com
2015-08-27 22:22 ` [Bug glob/16976] " jsm28 at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).