[Bug libc/2459] New: Use of uninitialised variable in fnmatch when matching long strings

[Bug libc/2459] New: Use of uninitialised variable in fnmatch when matching long strings

[richard at ex-parrot dot com]

In fnmatch() in posix/fnmatch.c, the variable wstring is left uninitialised if
strlen(string) >= 1024.  This appears to the cause of segfaults in GNU ld when
heavily templated C++ results in very long ELF section names.

-- 
           Summary: Use of uninitialised variable in fnmatch when matching
                    long strings
           Product: glibc
           Version: 2.3.6
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: richard at ex-parrot dot com
                CC: glibc-bugs at sources dot redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=2459

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/2459] Use of uninitialised variable in fnmatch when matching long strings

[richard at ex-parrot dot com]

------- Additional Comments From richard at ex-parrot dot com  2006-03-14 14:59 -------
Created an attachment (id=918)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=918&action=view)
Suggested fix for bug

The attached patch fixes it by initialising wstring in the same way as
wpattern.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2459

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/2459] Use of uninitialised variable in fnmatch when matching long strings

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2006-03-14 15:05 -------
I think you first need to answer what libc you are patching, because there
is no such code in glibc 2.4 nor glibc 2.3.6.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=2459

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/2459] Use of uninitialised variable in fnmatch when matching long strings

[richard at ex-parrot dot com]

------- Additional Comments From richard at ex-parrot dot com  2006-03-14 15:15 -------
It's against the code added in CVS version 1.50.4.1 on the glibc-2_3-branch:

2005-03-29  Jakub Jelinek  <jakub@redhat.com>

	[BZ #1087]
	* posix/fnmatch.c (fnmatch): For short patterns or strings attempt to
	avoid calling mbsrtowcs twice.

or the equivalent code in 1.51 on CVS head.

(I'm actually using a version of 2.3.6 with a significant set of additional
vendor patches.)

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2459

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/2459] Use of uninitialised variable in fnmatch when matching long strings

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2006-03-14 15:23 -------
glibc-2_3-branch has:
#ifdef _LIBC
      n = strnlen (string, 1024);
#else
      n = strlen (string);
#endif
      p = string;
      if (__builtin_expect (n < 1024, 1))
        {
          wstring = (wchar_t *) alloca ((n + 1) * sizeof (wchar_t));
          n = mbsrtowcs (wstring, &p, n + 1, &ps);
          if (__builtin_expect (n == (size_t) -1, 0))
            /* Something wrong.
               XXX Do we have to set `errno' to something which mbsrtows hasn't
               already done?  */
            return -1;
          if (p)
            memset (&ps, '\0', sizeof (ps));
        }
      if (__builtin_expect (p != NULL, 0))
        {
          n = mbsrtowcs (NULL, &string, 0, &ps);
          if (__builtin_expect (n == (size_t) -1, 0))
            /* Something wrong.
               XXX Do we have to set `errno' to something which mbsrtows hasn't
               already done?  */
            return -1;
          wstring = (wchar_t *) alloca ((n + 1) * sizeof (wchar_t));
          assert (mbsinit (&ps));
          (void) mbsrtowcs (wstring, &string, n + 1, &ps);
        }

      return internal_fnwmatch (wpattern, wstring, wstring + n,
                                flags & FNM_PERIOD, flags);

No try_singlebyte label and I don't see how can wstring end up being
uninitialized (well, GCC will warn, but that's GCC deficiency).

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2459

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/2459] Use of uninitialised variable in fnmatch when matching long strings

[richard at ex-parrot dot com]

------- Additional Comments From richard at ex-parrot dot com  2006-03-14 15:41 -------
*Embarassed pause*

Sorry about that -- I should have checked more carefully precisely what my
distribution (Gentoo) was doing to that file.  Having found one patch to that
function, I failed to notice a second one that introduces this bug by deleting
the line

  wstring = (wchar_t *) alloca ((n + 1) * sizeof (wchar_t));

Anyway, this is clearly Gentoo's bug not yours.  Sorry to have inconvenienced
you with it.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2459

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/2459] Use of uninitialised variable in fnmatch when matching long strings

[aj at suse dot de]

------- Additional Comments From aj at suse dot de  2006-03-15 08:49 -------
Ok, let's close since this is a Gentoo bug.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=2459

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.