This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/16009] Possible buffer overflow in strxfrm
- From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 31 Dec 2015 16:49:50 +0000
- Subject: [Bug libc/16009] Possible buffer overflow in strxfrm
- Auto-submitted: auto-generated
- References: <bug-16009-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16009
--- Comment #7 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, 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 -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b057b4813c9f05c3cedff0c74b58c9c9d583f09f
commit b057b4813c9f05c3cedff0c74b58c9c9d583f09f
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.
(cherry picked from commit 0f9e585480edcdf1e30dc3d79e24b84aeee516fa)
Conflicts:
NEWS
string/strxfrm_l.c
-----------------------------------------------------------------------
Summary of changes:
ChangeLog | 16 ++
NEWS | 4 +-
localedata/sort-test.sh | 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.