* [Bug libc/16009] Possible buffer overflow in strxfrm
[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
` (5 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2013-10-07 16:13 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16009
Joseph Myers <jsm28 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |siddhesh at redhat dot com
--- Comment #1 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
That bug was meant to cover strxfrm as well as strcoll but appears to have been
closed without fixing the strxfrm case....
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug libc/16009] Possible buffer overflow in strxfrm
[not found] <bug-16009-131@http.sourceware.org/bugzilla/>
2013-10-07 16:13 ` [Bug libc/16009] Possible buffer overflow in strxfrm 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
` (4 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: siddhesh at redhat dot com @ 2013-10-07 16:20 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16009
Siddhesh Poyarekar <siddhesh at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at sourceware dot org |siddhesh at redhat dot com
--- Comment #2 from Siddhesh Poyarekar <siddhesh at redhat dot com> ---
(In reply to Joseph Myers from comment #1)
> That bug was meant to cover strxfrm as well as strcoll but appears to have
> been closed without fixing the strxfrm case....
Ah ok, that didn't occur to me. I'll take this.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug libc/16009] Possible buffer overflow in strxfrm
[not found] <bug-16009-131@http.sourceware.org/bugzilla/>
2013-10-07 16:13 ` [Bug libc/16009] Possible buffer overflow in strxfrm 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
` (3 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: mancha1 at hush dot com @ 2013-10-30 5:20 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16009
mancha <mancha1 at hush dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mancha1 at hush dot com
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug libc/16009] Possible buffer overflow in strxfrm
[not found] <bug-16009-131@http.sourceware.org/bugzilla/>
` (2 preceding siblings ...)
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
` (2 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: fweimer at redhat dot com @ 2014-06-13 12:41 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16009
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fweimer at redhat dot com
Flags| |security+
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug libc/16009] Possible buffer overflow in strxfrm
[not found] <bug-16009-131@http.sourceware.org/bugzilla/>
` (3 preceding siblings ...)
2014-06-13 12:41 ` fweimer at redhat dot com
@ 2015-01-13 6:27 ` cvs-commit at gcc dot gnu.org
2015-01-13 6:28 ` siddhesh at redhat dot com
2015-02-17 7:25 ` cvs-commit at gcc dot gnu.org
6 siblings, 0 replies; 7+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2015-01-13 6:27 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug libc/16009] Possible buffer overflow in strxfrm
[not found] <bug-16009-131@http.sourceware.org/bugzilla/>
` (4 preceding siblings ...)
2015-01-13 6:27 ` cvs-commit at gcc dot gnu.org
@ 2015-01-13 6:28 ` siddhesh at redhat dot com
2015-02-17 7:25 ` cvs-commit at gcc dot gnu.org
6 siblings, 0 replies; 7+ messages in thread
From: siddhesh at redhat dot com @ 2015-01-13 6:28 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16009
Siddhesh Poyarekar <siddhesh at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Siddhesh Poyarekar <siddhesh at redhat dot com> ---
Fixed in master.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug libc/16009] Possible buffer overflow in strxfrm
[not found] <bug-16009-131@http.sourceware.org/bugzilla/>
` (5 preceding siblings ...)
2015-01-13 6:28 ` siddhesh at redhat dot com
@ 2015-02-17 7:25 ` cvs-commit at gcc dot gnu.org
6 siblings, 0 replies; 7+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2015-02-17 7:25 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16009
--- Comment #6 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.20/master has been updated
via 4d54424420c6300efbf57a7b9aa8635a8b8c1942 (commit)
via 1bf9d48aec087062e2a14b77cb5ee1fa81be334c (commit)
via f9e0f439b72e0b2fb035be1bc60aaceeed7f6ed0 (commit)
via b0694b9e98ee64cb25490de0921ce307f3872749 (commit)
from f80af76648ed97a76745fad6caa3315a79cb1c7c (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=4d54424420c6300efbf57a7b9aa8635a8b8c1942
commit 4d54424420c6300efbf57a7b9aa8635a8b8c1942
Author: Paul Pluzhnikov <ppluzhnikov@google.com>
Date: Fri Feb 6 00:30:42 2015 -0500
CVE-2015-1472: wscanf allocates too little memory
BZ #16618
Under certain conditions wscanf can allocate too little memory for the
to-be-scanned arguments and overflow the allocated buffer. The
implementation now correctly computes the required buffer size when
using malloc.
A regression test was added to tst-sscanf.
(cherry picked from commit 5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06)
Conflicts:
ChangeLog
NEWS
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=1bf9d48aec087062e2a14b77cb5ee1fa81be334c
commit 1bf9d48aec087062e2a14b77cb5ee1fa81be334c
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Fri Jan 30 06:50:20 2015 -0800
Use AVX unaligned memcpy only if AVX2 is available
memcpy with unaligned 256-bit AVX register loads/stores are slow on older
processorsl like Sandy Bridge. This patch adds bit_AVX_Fast_Unaligned_Load
and sets it only when AVX2 is available.
[BZ #17801]
* sysdeps/x86_64/multiarch/init-arch.c (__init_cpu_features):
Set the bit_AVX_Fast_Unaligned_Load bit for AVX2.
* sysdeps/x86_64/multiarch/init-arch.h (bit_AVX_Fast_Unaligned_Load):
New.
(index_AVX_Fast_Unaligned_Load): Likewise.
(HAS_AVX_FAST_UNALIGNED_LOAD): Likewise.
* sysdeps/x86_64/multiarch/memcpy.S (__new_memcpy): Check the
bit_AVX_Fast_Unaligned_Load bit instead of the bit_AVX_Usable bit.
* sysdeps/x86_64/multiarch/memcpy_chk.S (__memcpy_chk): Likewise.
* sysdeps/x86_64/multiarch/mempcpy.S (__mempcpy): Likewise.
* sysdeps/x86_64/multiarch/mempcpy_chk.S (__mempcpy_chk): Likewise.
* sysdeps/x86_64/multiarch/memmove.c (__libc_memmove): Replace
HAS_AVX with HAS_AVX_FAST_UNALIGNED_LOAD.
* sysdeps/x86_64/multiarch/memmove_chk.c (__memmove_chk): Likewise.
(cherry picked from commit 5f3d0b78e011d2a72f9e88b0e9ef5bc081d18f97)
Conflicts:
ChangeLog
NEWS
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f9e0f439b72e0b2fb035be1bc60aaceeed7f6ed0
commit f9e0f439b72e0b2fb035be1bc60aaceeed7f6ed0
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:
ChangeLog
NEWS
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b0694b9e98ee64cb25490de0921ce307f3872749
commit b0694b9e98ee64cb25490de0921ce307f3872749
Author: Roland McGrath <roland@hack.frob.com>
Date: Thu Sep 11 16:02:17 2014 -0700
Move findidx nested functions to top-level.
Needed in order to backport strxfrm_l security fix cleanly.
(cherry picked from commit 8c0ab919f63dc03a420751172602a52d2bea59a8)
Conflicts:
ChangeLog
-----------------------------------------------------------------------
Summary of changes:
ChangeLog | 77 +++++
NEWS | 8 +-
locale/weight.h | 13 +-
locale/weightwc.h | 13 +-
localedata/sort-test.sh | 7 +
localedata/xfrm-test.c | 52 +++-
posix/fnmatch.c | 8 +
posix/fnmatch_loop.c | 17 +-
posix/regcomp.c | 10 +-
posix/regex_internal.h | 7 +-
posix/regexec.c | 8 +-
stdio-common/tst-sscanf.c | 33 +++
stdio-common/vfscanf.c | 12 +-
string/strcoll_l.c | 9 +-
string/strxfrm_l.c | 491 +++++++++++++++++++++++++-------
sysdeps/x86_64/multiarch/init-arch.c | 9 +-
sysdeps/x86_64/multiarch/init-arch.h | 4 +
sysdeps/x86_64/multiarch/memcpy.S | 2 +-
sysdeps/x86_64/multiarch/memcpy_chk.S | 2 +-
sysdeps/x86_64/multiarch/memmove.c | 2 +-
sysdeps/x86_64/multiarch/memmove_chk.c | 2 +-
sysdeps/x86_64/multiarch/mempcpy.S | 2 +-
sysdeps/x86_64/multiarch/mempcpy_chk.S | 2 +-
23 files changed, 642 insertions(+), 148 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread