Age | Commit message (Collapse) | Author | Files | Lines |
|
https://bugs.gentoo.org/74948
(cherry picked from commit e8b6be0016f131c2ac72bf3213eabdb59800e63b)
(cherry picked from commit e04da210f7cd564c46a8db0e15a0c6e726f3977e)
|
|
* A stack-based buffer overflow was found in libresolv when invoked from
libnss_dns, allowing specially crafted DNS responses to seize control
of execution flow in the DNS client. The buffer overflow occurs in
the functions send_dg (send datagram) and send_vc (send TCP) for the
NSS module libnss_dns.so.2 when calling getaddrinfo with AF_UNSPEC
family. The use of AF_UNSPEC triggers the low-level resolver code to
send out two parallel queries for A and AAAA. A mismanagement of the
buffers used for those queries could result in the response of a query
writing beyond the alloca allocated buffer created by
_nss_dns_gethostbyname4_r. Buffer management is simplified to remove
the overflow. Thanks to the Google Security Team and Red Hat for
reporting the security impact of this issue, and Robert Holiday of
Ciena for reporting the related bug 18665. (CVE-2015-7547)
See also:
https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
https://sourceware.org/ml/libc-alpha/2016-02/msg00418.html
(cherry picked from commit e9db92d3acfe1822d56d11abcea5bfc4c41cf6ca)
(cherry picked from commit 16d0a0ce7613552301786bf05d7eba8784b5732c)
|
|
(cherry picked from commit bae7c7c764413b23e61cb099ce33be4c4ee259bb)
(cherry picked from commit 965630aefa60ad5f9d8e475ecd8618180f93ec60)
|
|
Hi,
As in bugzilla entry there is overflow in hsearch when looking for prime
number as SIZE_MAX - 1 is divisible by 5. We fix that by rejecting large
inputs before looking for prime.
* misc/hsearch_r.c (__hcreate_r): Handle overflow.
(cherry picked from commit 2f5c1750558fe64bac361f52d6827ab1bcfe52bc)
(cherry picked from commit 51e762570e41074a7d9be5b0ee8761f037fc6e68)
|
|
(cherry picked from commit d36c75fc0d44deec29635dd239b0fbd206ca49b7)
(cherry picked from commit 163437ec37ea32e82469de9b6cbed0d7209551c1)
|
|
(cherry picked from commit 0f58539030e436449f79189b6edab17d7479796e)
(cherry picked from commit 907cc11c576a21ea6df5f5ad0a2b1dc3b55dd553)
|
|
Robin Hack discovered Samba would enter an infinite loop processing
certain quota-related requests. We eventually tracked this down to a
glibc issue.
Running a (simplified) test case under strace shows that /etc/passwd
is continuously opened and closed:
…
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
lseek(3, 0, SEEK_CUR) = 0
read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 2717
lseek(3, 2717, SEEK_SET) = 2717
close(3) = 0
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
lseek(3, 0, SEEK_CUR) = 0
lseek(3, 0, SEEK_SET) = 0
read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 2717
lseek(3, 2717, SEEK_SET) = 2717
close(3) = 0
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
lseek(3, 0, SEEK_CUR) = 0
…
The lookup function implementation in
nss/nss_files/files-XXX.c:DB_LOOKUP has code to prevent that. It is
supposed skip closing the input file if it was already open.
/* Reset file pointer to beginning or open file. */ \
status = internal_setent (keep_stream); \
\
if (status == NSS_STATUS_SUCCESS) \
{ \
/* Tell getent function that we have repositioned the file pointer. */ \
last_use = getby; \
\
while ((status = internal_getent (result, buffer, buflen, errnop \
H_ERRNO_ARG EXTRA_ARGS_VALUE)) \
== NSS_STATUS_SUCCESS) \
{ break_if_match } \
\
if (! keep_stream) \
internal_endent (); \
} \
keep_stream is initialized from the stayopen flag in internal_setent.
internal_setent is called from the set*ent implementation as:
status = internal_setent (stayopen);
However, for non-host database, this flag is always 0, per the
STAYOPEN magic in nss/getXXent_r.c.
Thus, the fix is this:
- status = internal_setent (stayopen);
+ status = internal_setent (1);
This is not a behavioral change even for the hosts database (where the
application can specify the stayopen flag) because with a call to
sethostent(0), the file handle is still not closed in the
implementation of gethostent.
(cherry picked from commit 03d2730b44cc2236318fd978afa2651753666c55)
Conflicts:
ChangeLog
NEWS
(cherry picked from commit e871e19b5f19d2e6595e911b0a5b1c19cda20cc7)
|
|
The fix for BZ #17273 introduced a single byte of memory corruption when
the line is entirely blank. It would walk back past the start of the
buffer if the heap happened to be 0x20 or 0x09 and then write a NUL byte.
buffer = '\n';
end_ptr = buffer;
while (end_ptr[-1] == ' ' || end_ptr[-1] == '\t')
end_ptr--;
*end_ptr = '\0';
Fix that and rework the tests. Adding the testcase for BZ #17273 to the
existing \040 parser does not really make sense as it's unrelated, and
leads to confusing behavior: it implicitly relies on the new entry being
longer than the previous entry (since it just rewinds the FILE*). Split
it out into its own dedicated testcase instead.
(cherry picked from commit b0e805fa0d6fea33745952df7b7f5442ca4c374f)
(cherry picked from commit f2cdbadd8a078482d3b9fc2b59e888c64cc4efae)
|
|
Way back in 2005 the atomic_exchange_and_add function was cleaned up to
avoid the explicit size checking and instead let gcc handle things itself.
Unfortunately that change ended up leaving beyond a cast to int, even when
the incoming value was a long. This has flown under the radar for a long
time due to the function not being heavily used in the tree (especially as
a full 64bit field), but a recent change to semaphores made some nptl tests
fail reliably. This is due to the code packing two 32bit values into one
64bit variable (where the high 32bits contained the number of waiters), and
then the whole variable being atomically updated between threads. On ia64,
that meant we never atomically updated the count, so sometimes the sem_post
would not wake up the waiters.
(cherry picked from commit cf31a2c79957936b60de34ea1e718e892baf669c)
(cherry picked from commit 978908245b2c0f759100708a9966649f7b273664)
|
|
(cherry picked from commit bdf1ff052a8e23d637f2c838fa5642d78fcedc33)
(cherry picked from commit 8a4e5cc6574a419d5724bef6be98d705d58db48d)
|
|
(cherry picked from commit 4a28f4d55a6cc33474c0792fe93b5942d81bf185)
(cherry picked from commit fe7b1136e5753c85b3ccc8395dfc66b82052d73c)
|
|
Commit a059d359d86130b5fa74e04a978c8523a0293f77 changed the sigaction
struct to pass conform tests, but it ended up also changing the ABI for
32 bit builds. For 64 bit builds, changing the long to two ints works,
but for 32 bit builds, it inserts 4 extra bytes. This leads to many
packages randomly failing like bash that spews things like:
configure: line 471: wait_for: No record of process 0
Bracket the new member by a wordsize check to fix the ABI for 32bit.
(cherry picked from commit 7fde904c73c57faea48c9679bbdc0932d81b3a2f)
(cherry picked from commit d679497db20c23e3aaaa150821ce9134cc666a18)
|
|
(cherry picked from commit 2959eda9272a033863c271aff62095abd01bd4e3)
(cherry picked from commit 01b07c70ad77ef28b6a3661ed3142ebff35b6e69)
|
|
In commit 8b4416d, the 1: jump label in __mempcpy_chk was accidentally
moved. This resulted in failures of mempcpy on CPU without SSE2.
(cherry picked from commit 132a1328eccd20621b77f7810eebbeec0a1af187)
(cherry picked from commit 75adf430d2d7ee16eaf3166680de83b498444720)
|
|
When the compiler builds PIEs by default, the configure PIC check is
confused into thinking PIC code is default. The end result is that
we end up with only PIC being produced.
Run the configure check with -fno-PIE so that we produce PIC & non-PIC
(PIE) objects like normal.
2014-09-09 Kevin F. Quinn <kevquinn@gentoo.org>
* configure.ac (libc_cv_pic_default): Pass -fno-PIE.
* configure: Regenerated.
|
|
|
|
|
|
|
|
Specifically:
../sysdeps/unix/sysv/linux/hppa/bits/atomic.h:68:6: error:
can’t find a register in class ‘R1_REGS’ while reloading ‘asm’
|
|
the logic in setjmp/__longjmp incorrectly tie to "PIC" to figure out
whether the code is going into a shared library when it should be using
"SHARED". otherwise, building static PIC code goes wrong.
https://bugs.gentoo.org/336914
http://sourceware.org/ml/libc-ports/2011-09/msg00018.html
2011-09-19 David Lamparter <equinox-gentoo@diac24.net>
* sysdeps/arm/setjmp.S: Change PIC to SHARED.
* sysdeps/arm/__longjmp.S: Likewise
|
|
We've split this out into the package sys-libs/timezone-data
|
|
when glibc runs its tests, it does so by invoking the local library loader.
in Gentoo, we build/run inside of our "sandbox" which itself is linked against
libdl (so that it can load libraries and pull out symbols). the trouble
is that when you upgrade from an older glibc to the new one, often times
internal symbols change name or abi. this is normally OK as you cannot use
libc.so from say version 2.3.6 but libpthread.so from say version 2.5, so
we always say "keep all of the glibc libraries from the same build". but
when glibc runs its tests, it uses dynamic paths to point to its new local
copies of libraries. if the test doesnt use libdl, then glibc doesnt add
its path, and when sandbox triggers the loading of libdl, glibc does so
from the host system system. this gets us into the case of all libraries
are from the locally compiled version of glibc except for libdl.so.
http://bugs.gentoo.org/56898
|
|
https://bugs.gentoo.org/452184
http://sourceware.org/bugzilla/show_bug.cgi?id=15005
http://sourceware.org/ml/libc-alpha/2013-01/msg00247.html
|
|
http://bugs.gentoo.org/301642
|
|
if /etc/resolv.conf is updated, then make sure applications
already running get the updated information.
ripped from SuSE
http://bugs.gentoo.org/177416
|
|
http://bugs.debian.org/198099
http://bugs.debian.org/231438
|
|
the fortify/optimization check does not play well with our default gcc specs
http://sourceware.org/ml/libc-alpha/2012-06/msg00068.html
|
|
work around ... not entirely sure what is going on here.
2011-03-01 squeezy <vina@mailserver.eu>
* sysdeps/unix/sysv/linux/x86_64/sigaction.c fix the __restore_rt symbol
http://bugs.gentoo.org/283470
|
|
do not bother running ldconfig on DESTDIR. it wants to write the temp cache
file outside of the chroot. doesnt matter anyways as we wont use the cache
results (portage will rebuild cache), so running ldconfig is simply a waste
of time.
http://sourceware.org/ml/libc-alpha/2012-08/msg00118.html
https://bugs.gentoo.org/431038
|
|
|
|
This reverts part of the previous commit to refactor pthread.h.
The refactoring must be done by having pthread.h include arch
bits headers, not the other way around. Then hppa provides the
arch bits header. For now we synchronzie again with pthread.h
and include the entire contents in the hppa copy.
|
|
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.
|
|
Update all translations.
Update contributions in the manual.
Update installation notes with information about newest working tools.
Reconfigure using exactly autoconf 2.69.
Regenerate INSTALL.
|
|
(1) Fix warnings.
This is a bulk update to fix all the warnings that were causing
build failures with -Werror on hppa.
The most egregious problems are in dl-fptr.c which needs to be
entirely rewritten, thus I've used -Wno-error for that.
(2) Fix conformance errors.
The sysdep.c file had __syscall_error and syscall in one file
which caused conformance issues by including syscall when
__syscall_error was linked to. The fix is obviously to split
the file and use syscall.c to implement syscall.
|
|
|
|
* sysdeps/sparc/sparc32/bits/atomic.h
(__sparc32_atomic_do_unlock24): Put the memory barrier before the
unlock not after it.
(__v9_compare_and_exchange_val_32_acq): Use unions to avoid getting
volatile register usage warnings from the compiler.
|
|
* sysdeps/sparc/nptl/sem_init.c: Delete.
* sysdeps/sparc/nptl/sem_post.c: Delete.
* sysdeps/sparc/nptl/sem_timedwait.c: Delete.
* sysdeps/sparc/nptl/sem_wait.c: Delete.
* sysdeps/sparc/sparc32/sem_init.c: New file.
* sysdeps/sparc/sparc32/sem_waitcommon.c: New file.
* sysdeps/sparc/sparc32/sem_open.c: Generic nptl version with
padding explicitly initialized.
* sysdeps/sparc/sparc32/sem_post.c: Generic nptl version using
padding for in-semaphore spinlock.
* sysdeps/sparc/sparc32/sem_wait.c: Likewise.
* sysdeps/sparc/sparc32/sem_trywait.c: Delete.
* sysdeps/sparc/sparc32/sem_timedwait.c: Delete.
* sysdeps/sparc/sparc32/sparcv9/sem_init.c: New file.
* sysdeps/sparc/sparc32/sparcv9/sem_open.c: New file.
* sysdeps/sparc/sparc32/sparcv9/sem_post.c: New file.
* sysdeps/sparc/sparc32/sparcv9/sem_waitcommon.c: New file.
* sysdeps/sparc/sparc32/sparcv9/sem_wait.c: Redirect to nptl
version.
* sysdeps/sparc/sparc32/sparcv9/sem_timedwait.c: Delete.
* sysdeps/sparc/sparc32/sparcv9/sem_trywait.c: Delete.
|
|
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.
|
|
Architectures which don't use hp-timing-common.h don't include <signal.h>
via <sys/param.h>.
|
|
|
|
The padding bytes in the statsdata struct are not initialized, due to
which valgrind throws a warning:
==11384== Memcheck, a memory error detector
==11384== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==11384== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==11384== Command: nscd -d
==11384==
Fri 25 Apr 2014 10:34:53 AM CEST - 11384: handle_request: request received (Version = 2) from PID 11396
Fri 25 Apr 2014 10:34:53 AM CEST - 11384: GETSTAT
==11384== Thread 6:
==11384== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==11384== at 0x4E4ACDC: send (in /lib64/libpthread-2.12.so)
==11384== by 0x11AF6B: send_stats (in /usr/sbin/nscd)
==11384== by 0x112F75: nscd_run_worker (in /usr/sbin/nscd)
==11384== by 0x4E439D0: start_thread (in /lib64/libpthread-2.12.so)
==11384== by 0x599AB6C: clone (in /lib64/libc-2.12.so)
==11384== Address 0x15708395 is on thread 6's stack
Fix the warning by initializing the structure.
|
|
|
|
This is because of alignment issues in the sem_t support.
tilegx32 does in fact support 64-bit atomics and we will need
to revisit this after the 2.21 freeze.
|
|
This patch disables use of 64-bit atomics for MIPS n32 to fix the
problems with unaligned semaphores.
Before 64-bit atomics are used for anything for which such alignment
issues do not arise, and before the addition of any new ILP32 ports
with 64-bit semaphores for which the ABI can be set to have the
greater alignment (AARCH64?), a better approach will need to be
established that allows architectures to declare their 64-bit atomics
availability accurately, without doing so causing inappropriate use of
such atomics on unaligned semaphores.
Tested for MIPS n32 that this fixes the nptl/tst-sem3 failure.
* sysdeps/mips/bits/atomic.h [_MIPS_SIM == _ABIN32]
(__HAVE_64B_ATOMICS): Define to 0.
|
|
This patch fixes a bug introduced by 18f2945ae9216cfc, where it optimizes
the FPSCR set by just issuing a mtfs instruction if new flag is different
from older one. The issue is a typo, where the new flag should the the
new value, instead of the old one.
It fixes BZ#17885.
|
|
Some powerpc64 processors (e5500 core for instance) does not provide the
fsqrt instruction, however current check to use in math_private.h is
__WORDSIZE and _ARCH_PWR4 (ISA 2.02). This is patch change it to use
the compiler flag _ARCH_PPCSQ (which is the same condition GCC uses to
decide whether to generate fsqrt instruction).
It fixes BZ#16576.
|
|
|
|
|
|
|
|
|