From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24256 invoked by alias); 13 Jan 2015 06:27:34 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 24216 invoked by uid 55); 13 Jan 2015 06:27:28 -0000 From: "cvs-commit at gcc dot gnu.org" To: glibc-bugs@sourceware.org Subject: [Bug libc/16009] Possible buffer overflow in strxfrm Date: Tue, 13 Jan 2015 06:27:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: siddhesh at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-01/txt/msg00103.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16009 --- Comment #3 from 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 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.