Fixes to address issues from BZ #15022 resolution, as follows:
* TLS updates to csu/libc-tls.c -- we now have a proper main map, so
there's no longer a need to create a separate fake one to keep TLS
structures,
* random updates to elf/dl-close.c -- LM_ID_BASE is now a valid name
space ID for static executables as well, so assert that we don't
unload the main map. Similarly dl_nns isn't supposed to be 0 for
static executables anymore,
* actual BZ #16046 fix to elf/dl-iteratephdr.c -- the dl_iterate_phdr
special function for static executables isn't needed anymore, provided
that l_phdr and l_phnum members of the main map have been properly
initialized (done in _dl_non_dynamic_init in elf/dl-support.c now),
* ld.so.cache loader update to elf/dl-load.c --
GL(dl_ns)[LM_ID_BASE]._ns_loaded is now always initialized in static
executables so can become the fallback loader map to check for
DF_1_NODEFLIB, provided that the l_flags_1 member of the main map has
been properly initialized (done in elf/dl-support.c now); this also
ensures previous semantics elsewhere in elf/dl-load.c,
* matching updates to elf/dl-support.c -- to complement the two fixes
above.
When i386 and x86-64 mathinline.h was merged into a single mathinline.h,
"gcc -m32" enables x87 inline functions on x86-64 even when -mfpmath=sse
and SSE2 is enabled. It is a regression on x86-64. We should check
__SSE2_MATH__ instead of __x86_64__ when disabling x87 inline functions.
The netgroups file parsing code tries to access the character before
the newline in parsed lines to see if it is a backslash (\). This
results in an access before the block allocated for the line if the
line is blank, i.e. does not have anything other than the newline
character. This doesn't seem like it will cause any crashes because
the byte belongs to the malloc metadata block and hence access to it
will always succeed.
There could be an invalid alteration in code flow where a blank line
is seen as a continuation due to the preceding byte *happening* to be
'\\'. This could be done by interposing malloc, but that's not really
a security problem since one could interpose getnetgrent_r itself and
achieve a similar 'exploit'.
The possibility of actually exploiting this is remote to impossible
since it also requires the previous line to end with a '\\', which
would happen only on invalid configurations.
The _nss_*_getnetgrent_r query populates the netgroup results in the
allocated buffer and then sets the result triplet to point to strings
in the buffer. This is a problem when the buffer is reallocated since
the pointers to the triplet strings are no longer valid. The pointers
need to be adjusted so that they now point to strings in the
reallocated buffer.
In BZ #15605 fix with addding memset/memmove alias in symbol-hacks.h,
x32 symbol-hacks.h change was missing. Fixed by including
<sysdeps/generic/symbol-hacks.h> in x32 symbol-hacks.h.
The IFUNC selector for gettimeofday runs before _libc_vdso_platform_setup where
__vdso_gettimeofday is set. The selector then sets __gettimeofday (the internal
version used within GLIBC) to use the system call version instead of the vDSO one.
This patch changes the check if vDSO is available to get its value directly
instead of rely on __vdso_gettimeofday.
This patch changes it by getting the vDSO value directly.
It fixes BZ#16431.
See commit 41b1792698 for testcase.
Note: while this works on s390x, the s390 code hangs when using -e.
But it hangs regardless of this code (the hang seems to occur before
the exit func is even called). I didn't look too closely at it as
it seems to be an issue external to this file, so this code shouldn't
make the situation any worse.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This patches fixes BZ#16430 by setting a different symbol for internal
GLIBC calls that points to ifunc resolvers. For PPC32, if the symbol
is defined as hidden (which is the case for gettimeofday and time) the
compiler will create local branches (symbol@local) and linker will not
create PLT calls (required for IFUNC). This will leads to internal symbol
calling the IFUNC resolver instead of the resolved symbol.
For PPC64 this behavior does not occur because a call to a function in
another translation unit might use a different toc pointer thus requiring
a PLT call.
ARM has an override of the test math/test-fpucw.c, to disable (for
soft-float testing) definitions of hard-float macros in fpu_control.h
that the header normally defines not only when building for
hard-float, but also when building for soft-float with _LIBC defined
so that libc code can dynamically test whether VFP hardware is
present. (_LIBC is defined when building tests, although ideally it
wouldn't be.)
The override doesn't work for the derived tests test-fpucw-*.c because
they use #include "" instead of <> to include test-fpucw.c, so always
get the math/ version instead of the ARM sysdeps override. This patch
changes them to use <> so the sysdeps override is effective.
(test-fpucw-ieee-static.c doesn't need a change because it includes
test-fpucw-ieee.c, which isn't itself being overridden, which in turn
includes test-fpucw.c with a #include changed by this patch.)
Tested for ARM (big-endian soft-float, non-VFP hardware).
* math/test-fpucw-ieee.c: Use <> in #include of test-fpucw.c.
* math/test-fpucw-static.c: Likewise.
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.
