public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/16009] Possible buffer overflow in strxfrm
Date: Tue, 13 Jan 2015 06:27:00 -0000	[thread overview]
Message-ID: <bug-16009-131-PDjS5QY2Uz@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-16009-131@http.sourceware.org/bugzilla/>

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

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  0f9e585480edcdf1e30dc3d79e24b84aeee516fa (commit)
      from  c60ec0e016f9e2444c7bc2703fc6b671a26f0f5e (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0f9e585480edcdf1e30dc3d79e24b84aeee516fa

commit 0f9e585480edcdf1e30dc3d79e24b84aeee516fa
Author: Leonhard Holz <leonhard.holz@web.de>
Date:   Tue Jan 13 11:33:56 2015 +0530

    Fix memory handling in strxfrm_l [BZ #16009]

    [Modified from the original email by Siddhesh Poyarekar]

    This patch solves bug #16009 by implementing an additional path in
    strxfrm that does not depend on caching the weight and rule indices.

    In detail the following changed:

    * The old main loop was factored out of strxfrm_l into the function
    do_xfrm_cached to be able to alternativly use the non-caching version
    do_xfrm.

    * strxfrm_l allocates a a fixed size array on the stack. If this is not
    sufficiant to store the weight and rule indices, the non-caching path is
    taken. As the cache size is not dependent on the input there can be no
    problems with integer overflows or stack allocations greater than
    __MAX_ALLOCA_CUTOFF. Note that malloc-ing is not possible because the
    definition of strxfrm does not allow an oom errorhandling.

    * The uncached path determines the weight and rule index for every char
    and for every pass again.

    * Passing all the locale data array by array resulted in very long
    parameter lists, so I introduced a structure that holds them.

    * Checking for zero src string has been moved a bit upwards, it is
    before the locale data initialization now.

    * To verify that the non-caching path works correct I added a test run
    to localedata/sort-test.sh & localedata/xfrm-test.c where all strings
    are patched up with spaces so that they are too large for the caching path.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog               |   16 ++
 NEWS                    |   16 +-
 localedata/sort-test.sh |    7 +
 localedata/xfrm-test.c  |   52 +++++-
 string/strxfrm_l.c      |  488 ++++++++++++++++++++++++++++++++++++++---------
 5 files changed, 471 insertions(+), 108 deletions(-)

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


  parent reply	other threads:[~2015-01-13  6:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-16009-131@http.sourceware.org/bugzilla/>
2013-10-07 16:13 ` jsm28 at gcc dot gnu.org
2013-10-07 16:20 ` siddhesh at redhat dot com
2013-10-30  5:20 ` mancha1 at hush dot com
2014-06-13 12:41 ` fweimer at redhat dot com
2015-01-13  6:27 ` cvs-commit at gcc dot gnu.org [this message]
2015-01-13  6:28 ` siddhesh at redhat dot com
2015-02-17  7:25 ` cvs-commit at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-16009-131-PDjS5QY2Uz@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).