This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/16009] Possible buffer overflow in strxfrm

--- Comment #7 from cvs-commit at gcc dot <cvs-commit at gcc dot> ---
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, release/2.18/master has been updated
       via  b057b4813c9f05c3cedff0c74b58c9c9d583f09f (commit)
      from  325241608584653c1275a2ea28ce349a04fc4d28 (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 -----------------------------------------------------------------;h=b057b4813c9f05c3cedff0c74b58c9c9d583f09f

commit b057b4813c9f05c3cedff0c74b58c9c9d583f09f
Author: Leonhard Holz <>
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

    * 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/ & localedata/xfrm-test.c where all strings
    are patched up with spaces so that they are too large for the caching path.

    (cherry picked from commit 0f9e585480edcdf1e30dc3d79e24b84aeee516fa)



Summary of changes:
 ChangeLog               |   16 ++
 NEWS                    |    4 +-
 localedata/ |    6 +
 localedata/xfrm-test.c  |   52 +++++-
 string/strxfrm_l.c      |  499 ++++++++++++++++++++++++++++++++++++++---------
 5 files changed, 473 insertions(+), 104 deletions(-)

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]