diff options
author | Siddhesh Poyarekar <siddhesh@redhat.com> | 2014-01-16 10:20:22 +0530 |
---|---|---|
committer | Siddhesh Poyarekar <siddhesh@redhat.com> | 2014-01-16 10:21:52 +0530 |
commit | 980cb5180e1b71224a57ca52b995c959b7148c09 (patch) | |
tree | 132d22c6a5d1ea9993dcc3bf721f089b40857e49 /math/test-fpucw-static.c | |
parent | 2393fc0119fa291ff01b7b912dda2069257c8600 (diff) | |
download | glibc-980cb5180e1b71224a57ca52b995c959b7148c09.tar.gz glibc-980cb5180e1b71224a57ca52b995c959b7148c09.tar.xz glibc-980cb5180e1b71224a57ca52b995c959b7148c09.zip |
Don't use alloca in addgetnetgrentX (BZ #16453)
addgetnetgrentX has a buffer which is grown as per the needs of the requested size either by using alloca or by falling back to malloc if the size is larger than 1K. There are two problems with the alloca bits: firstly, it doesn't really extend the buffer since it does not use the return value of the extend_alloca macro, which is the location of the reallocated buffer. Due to this the buffer does not actually extend itself and hence a subsequent write may overwrite stuff on the stack. The second problem is more subtle - the buffer growth on the stack is discontinuous due to block scope local variables. Combine that with the fact that unlike realloc, extend_alloca does not copy over old content and you have a situation where the buffer just has garbage in the space where it should have had data. This could have been fixed by adding code to copy over old data whenever we call extend_alloca, but it seems unnecessarily complicated. This code is not exactly a performance hotspot (it's called when there is a cache miss, so factors like network lookup or file reads will dominate over memory allocation/reallocation), so this premature optimization is unnecessary. Thanks Brad Hubbard <bhubbard@redhat.com> for his help with debugging the problem.
Diffstat (limited to 'math/test-fpucw-static.c')
0 files changed, 0 insertions, 0 deletions