We can use long int on sparcv9, but on sparc64, we must match the int
type used by the kernel (and not long int, as in POSIX).
(cherry picked from commit 7c5e34d7f1)
The race leads either to pthread_mutex_destroy returning EBUSY
or triggering an assertion (See description in bugzilla).
This patch is fixing the race by ensuring that the elision path is
used in all cases if elision is enabled by the GLIBC_TUNABLES framework.
The __kind variable in struct __pthread_mutex_s is accessed concurrently.
Therefore we are now using the atomic macros.
The new testcase tst-mutex10 is triggering the race on s390x and intel.
Presumably also on power, but I don't have access to a power machine
with lock-elision. At least the code for power is the same as on the other
two architectures.
ChangeLog:
[BZ #23275]
* nptl/tst-mutex10.c: New File.
* nptl/Makefile (tests): Add tst-mutex10.
(tst-mutex10-ENV): New variable.
* sysdeps/unix/sysv/linux/s390/force-elision.h: (FORCE_ELISION):
Ensure that elision path is used if elision is available.
* sysdeps/unix/sysv/linux/powerpc/force-elision.h (FORCE_ELISION):
Likewise.
* sysdeps/unix/sysv/linux/x86/force-elision.h: (FORCE_ELISION):
Likewise.
* nptl/pthreadP.h (PTHREAD_MUTEX_TYPE, PTHREAD_MUTEX_TYPE_ELISION)
(PTHREAD_MUTEX_PSHARED): Use atomic_load_relaxed.
* nptl/pthread_mutex_consistent.c (pthread_mutex_consistent): Likewise.
* nptl/pthread_mutex_getprioceiling.c (pthread_mutex_getprioceiling):
Likewise.
* nptl/pthread_mutex_lock.c (__pthread_mutex_lock_full)
(__pthread_mutex_cond_lock_adjust): Likewise.
* nptl/pthread_mutex_setprioceiling.c (pthread_mutex_setprioceiling):
Likewise.
* nptl/pthread_mutex_timedlock.c (__pthread_mutex_timedlock): Likewise.
* nptl/pthread_mutex_trylock.c (__pthread_mutex_trylock): Likewise.
* nptl/pthread_mutex_unlock.c (__pthread_mutex_unlock_full): Likewise.
* sysdeps/nptl/bits/thread-shared-types.h (struct __pthread_mutex_s):
Add comments.
* nptl/pthread_mutex_destroy.c (__pthread_mutex_destroy):
Use atomic_load_relaxed and atomic_store_relaxed.
* nptl/pthread_mutex_init.c (__pthread_mutex_init):
Use atomic_store_relaxed.
(cherry picked from commit 403b4feb22)
The fallback code of Linux wrapper for preadv2/pwritev2 executes
regardless of the errno code for preadv2, instead of the case where
the syscall is not supported.
This fixes it by calling the fallback code iff errno is ENOSYS. The
patch also adds tests for both invalid file descriptor and invalid
iov_len and vector count.
The only discrepancy between preadv2 and fallback code regarding
error reporting is when an invalid flags are used. The fallback code
bails out earlier with ENOTSUP instead of EINVAL/EBADF when the syscall
is used.
Checked on x86_64-linux-gnu on a 4.4.0 and 4.15.0 kernel.
[BZ #23579]
* misc/tst-preadvwritev2-common.c (do_test_with_invalid_fd): New
test.
* misc/tst-preadvwritev2.c, misc/tst-preadvwritev64v2.c (do_test):
Call do_test_with_invalid_fd.
* sysdeps/unix/sysv/linux/preadv2.c (preadv2): Use fallback code iff
errno is ENOSYS.
* sysdeps/unix/sysv/linux/preadv64v2.c (preadv64v2): Likewise.
* sysdeps/unix/sysv/linux/pwritev2.c (pwritev2): Likewise.
* sysdeps/unix/sysv/linux/pwritev64v2.c (pwritev64v2): Likewise.
(cherry picked from commit 7a16bdbb9f)
If glibc is built with gcc 8 and -march=z900,
the testcase posix/tst-spawn4-compat crashes with a segfault.
In function maybe_script_execute, the new_argv array is dynamically
initialized on stack with (argc + 1) elements.
The function wants to add _PATH_BSHELL as the first argument
and writes out of bounds of new_argv.
There is an off-by-one because maybe_script_execute fails to count
the terminating NULL when sizing new_argv.
ChangeLog:
* sysdeps/unix/sysv/linux/spawni.c (maybe_script_execute):
Increment size of new_argv by one.
(cherry picked from commit 28669f86f6)
cpu-features.h has
#define bit_cpu_LZCNT (1 << 5)
#define index_cpu_LZCNT COMMON_CPUID_INDEX_1
#define reg_LZCNT
But the LZCNT feature bit is in COMMON_CPUID_INDEX_80000001:
Initial EAX Value: 80000001H
ECX Extended Processor Signature and Feature Bits:
Bit 05: LZCNT available
index_cpu_LZCNT should be COMMON_CPUID_INDEX_80000001, not
COMMON_CPUID_INDEX_1. The VMX feature bit is in COMMON_CPUID_INDEX_1:
Initial EAX Value: 01H
Feature Information Returned in the ECX Register:
5 VMX
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
[BZ #23456]
* sysdeps/x86/cpu-features.h (index_cpu_LZCNT): Set to
COMMON_CPUID_INDEX_80000001.
(cherry picked from commit 65d87ade1e)
Each weight is prefixed by its length, and the length does not include
itself in the count. This can be seen clearly from the find_idx
function in string/strxfrm_l.c, for example. The old code behaved as if
the length itself counted, thus comparing an additional byte after the
weight, leading to spurious comparison failures and incorrect further
partitioning of character equivalence classes.
(cherry picked from commit 7b2f4cedf0)
This suppresses Perl warnings like these:
Unescaped left brace in regex is deprecated here (and will be fatal in
Perl 5.32), passed through in regex; marked by <-- HERE in m/^element
*({ <-- HERE ([^}]*)}|([^{ ]*)) *({([^}]*)}|([^{ ]*)) *([A-Za-z0-9_]*)
*(.*)/ at conformtest.pl line 370.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
(cherry picked from commit ddb3c626b0)
Previously, only the SSE2 rounding mode was set, so the assembler
implementations using 387 were not following the expecting rounding
mode.
(cherry picked from commit f496b28e61)
A lookup operation in map_newlink could turn into an insert because of
holes in the interface part of the map. This leads to incorrectly set
the name of the interface to NULL when the interface is not present
for the address being processed (most likely because the interface was
added between the RTM_GETLINK and RTM_GETADDR calls to the kernel).
When such changes are detected by the kernel, it'll mark the dump as
"inconsistent" by setting NLM_F_DUMP_INTR flag on the next netlink
message.
This patch checks this condition and retries the whole operation.
Hopes are that next time the interface corresponding to the address
entry is present in the list and correct name is returned.
(cherry picked from commit c1f86a33ca)
After commit d76d370355 ("Fix missing
timespec definition for sys/stat.h (BZ #21371)") in combination with
kernel UAPI changes, GCC sanitizer builds start to fail due to a
conflicting definition of struct timespec in <linux/time.h>. Use
_STRUCT_TIMESPEC as the header file inclusion guard, which is already
checked in the kernel header, to support including <linux/time.h> and
<sys/stat.h> in the same translation unit.
(cherry picked from commit c1c2848b57)
The commit
commit c85e54ac6c
Author: Gabriel F. T. Gomes <gabriel@inconstante.eti.br>
Date: Fri Nov 3 10:44:36 2017 -0200
Provide a C++ version of iseqsig (bug 22377)
mistakenly used double parameters in the long double version of iseqsig,
thus causing spurious conversions to double, as reported on bug 23171.
Tested for powerpc64le and x86_64.
(cherry picked from commit fb0e10b8eb)
This commit improves DST handling significantly in the following
ways: firstly is_dst () is overhauled to correctly process DST
sequences that would be accepted given the ELF gABI. This means that
we actually now accept slightly more sequences than before. Now we
accept $ORIGIN$ORIGIN, but in the past we accepted only $ORIGIN\0 or
$ORIGIN/..., but this kind of behaviour results in unexpected
and uninterpreted DST sequences being used as literal search paths
leading to security defects. Therefore the first step in correcting
this defect is making is_dst () properly account for all DSTs
and making the function context free in the sense that it counts
DSTs without knowledge of path, or AT_SECURE. Next, _dl_dst_count ()
is also simplified to count all DSTs regardless of context.
Then in _dl_dst_substitute () we reintroduce context-dependent
processing for such things as AT_SECURE handling. At the level of
_dl_dst_substitute we can have access to things like the true start
of the string sequence to validate $ORIGIN-based paths rooted in
trusted directories. Lastly, we tighten up the accepted sequences
in AT_SECURE, and avoid leaving known unexpanded DSTs, this is
noted in the NEWS entry.
Verified with a sequence of 68 tests on x86_64 that cover
non-AT_SECURE and AT_SECURE testing using a sysroot (requires root
to run). The tests cover cases for bug 23102, bug 21942, bug 18018,
and bug 23259. These tests are not yet appropriate for the glibc
regression testsuite, but with the upcoming test-in-container testing
framework it should be possible to include these tests upstream soon.
See the mailing list for the tests:
https://www.sourceware.org/ml/libc-alpha/2018-06/msg00251.html
(cherry picked from commit 5aad5f6178)
Due to the way the conditions were written, the rtld build of strncmp
ended up with no definition of the strncmp symbol at all: The
implementations were renamed for use within an IFUNC resolver, but the
IFUNC resolver itself was missing (because rtld does not use IFUNCs).
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
(cherry picked from commit e826574c98)
The results are from configuring with and without
--disable-multi-arch, building with “-march=x86-64 -mtune=generic
-mfpmath=sse” and running the testsuite on a Haswell-era CPU.
Slightly higher ulps are required than in master (commit
e02c026f38).
Current posix_spawnp implementation wrongly tries to execute invalid
binaries (for instance script without shebang) as a shell script in
non compat mode. It was a regression introduced by
9ff72da471 when __spawni started to use
__execvpe instead of __execve (glibc __execvpe try to execute ENOEXEC
as shell script regardless).
This patch fixes it by using an internal symbol (__execvpex) with the
faulty semantic (since compat mode is handled by spawni.c itself).
It was reported by Daniel Drake on libc-help [1].
Checked on x86_64-linux-gnu and i686-linux-gnu.
[BZ #23264]
* include/unistd.h (__execvpex): New prototype.
* posix/Makefile (tests): Add tst-spawn4.
(tests-internal): Add tst-spawn4-compat.
* posix/execvpe.c (__execvpe_common, __execvpex): New functions.
* posix/tst-spawn4-compat.c: New file.
* posix/tst-spawn4.c: Likewise.
* sysdeps/unix/sysv/linux/spawni.c (__spawni): Do not interpret invalid
binaries as shell scripts.
* sysdeps/posix/spawni.c (__spawni): Likewise.
[1] https://sourceware.org/ml/libc-help/2018-06/msg00012.html
(cherry picked from commit 283d985122)
These unmangled function pointers reside on the heap and could
be targeted by exploit writers, effectively bypassing libio vtable
validation. Instead, we ignore these pointers and always call
malloc or free.
In theory, this is a backwards-incompatible change, but using the
global heap instead of the user-supplied callback functions should
have little application impact. (The old libstdc++ implementation
exposed this functionality via a public, undocumented constructor
in its strstreambuf class.)
(cherry picked from commit 4e8a6346cd)
When compiled as mempcpy, the return value is the end of the destination
buffer, thus it cannot be used to refer to the start of it.
(cherry picked from commit 9aaaab7c6e)
This is needed to avoid a warning when linking against libtirpc:
/lib64/libc.so.6: warning: common of `rpc_createerr@@TIRPC_0.3.0' overridden by definition
/usr/lib64/libtirpc.so: warning: defined here
This ld warning is not enabled by default; -Wl,--warn-common enables it.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
(cherry picked from commit 89aacb513e)
[BZ #23152]
* localedata/locales/gd_GB (abmon): Fix typo in May:
"Mhàrt" -> "Cèit". Adjust the comment according to the change.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
(cherry picked from commit bb066cb806)
Integer addition overflow may cause stack buffer overflow
when realpath() input length is close to SSIZE_MAX.
2018-05-09 Paul Pluzhnikov <ppluzhnikov@google.com>
[BZ #22786]
* stdlib/canonicalize.c (__realpath): Fix overflow in path length
computation.
* stdlib/Makefile (test-bz22786): New test.
* stdlib/test-bz22786.c: New test.
(cherry picked from commit 5460617d15)
A PT_NOTE in a binary could be arbitratily large, so using alloca
for it may cause stack overflow. If the note is larger than
__MAX_ALLOCA_CUTOFF, use dynamically allocated memory to read it in.
2018-05-05 Paul Pluzhnikov <ppluzhnikov@google.com>
[BZ #20419]
* elf/dl-load.c (open_verify): Fix stack overflow.
* elf/Makefile (tst-big-note): New test.
* elf/tst-big-note-lib.S: New.
* elf/tst-big-note.c: New.
(cherry picked from commit 0065aaaaae)
On s390 (31bit) if glibc is build with -Os, pthread_join sometimes
blocks indefinitely. This is e.g. observable with
testcase intl/tst-gettext6.
pthread_join is calling lll_wait_tid(tid), which performs the futex-wait
syscall in a loop as long as tid != 0 (thread is alive).
On s390 (and build with -Os), tid is loaded from memory before
comparing against zero and then the tid is loaded a second time
in order to pass it to the futex-wait-syscall.
If the thread exits in between, then the futex-wait-syscall is
called with the value zero and it waits until a futex-wake occurs.
As the thread is already exited, there won't be a futex-wake.
In lll_wait_tid, the tid is stored to the local variable __tid,
which is then used as argument for the futex-wait-syscall.
But unfortunately the compiler is allowed to reload the value
from memory.
With this patch, the tid is loaded with atomic_load_acquire.
Then the compiler is not allowed to reload the value for __tid from memory.
ChangeLog:
[BZ #23137]
* sysdeps/nptl/lowlevellock.h (lll_wait_tid):
Use atomic_load_acquire to load __tid.
(cherry picked from commit 1660901840)
This patch adds the PTRACE_SECCOMP_GET_METADATA constant from Linux
4.16 to all relevant sys/ptrace.h files. A type struct
__ptrace_seccomp_metadata, analogous to other such types, is also
added.
Tested for x86_64, and with build-many-glibcs.py.
* sysdeps/unix/sysv/linux/sys/ptrace.h
(PTRACE_SECCOMP_GET_METADATA): New enum value and macro.
* sysdeps/unix/sysv/linux/bits/ptrace-shared.h
(struct __ptrace_seccomp_metadata): New type.
* sysdeps/unix/sysv/linux/aarch64/sys/ptrace.h
(PTRACE_SECCOMP_GET_METADATA): Likewise.
* sysdeps/unix/sysv/linux/arm/sys/ptrace.h
(PTRACE_SECCOMP_GET_METADATA): Likewise.
* sysdeps/unix/sysv/linux/ia64/sys/ptrace.h
(PTRACE_SECCOMP_GET_METADATA): Likewise.
* sysdeps/unix/sysv/linux/powerpc/sys/ptrace.h
(PTRACE_SECCOMP_GET_METADATA): Likewise.
* sysdeps/unix/sysv/linux/s390/sys/ptrace.h
(PTRACE_SECCOMP_GET_METADATA): Likewise.
* sysdeps/unix/sysv/linux/sparc/sys/ptrace.h
(PTRACE_SECCOMP_GET_METADATA): Likewise.
* sysdeps/unix/sysv/linux/tile/sys/ptrace.h
(PTRACE_SECCOMP_GET_METADATA): Likewise.
* sysdeps/unix/sysv/linux/x86/sys/ptrace.h
(PTRACE_SECCOMP_GET_METADATA): Likewise.
(cherry picked from commit 9320ca88a1)
The example did not work because the null byte was not converted, and
mbrtowc was called with a zero-length input string. This results in a
(size_t) -2 return value, so the function always returns NULL.
The size computation for the heap allocation of the result was
incorrect because it did not deal with integer overflow.
Error checking was missing, and the allocated memory was not freed on
error paths. All error returns now set errno. (Note that there is an
assumption that free does not clobber errno.)
The slightly unportable comparision against (size_t) -2 to catch both
(size_t) -1 and (size_t) -2 return values is gone as well.
A null wide character needs to be stored in the result explicitly, to
terminate it.
The description in the manual is updated to deal with these finer
points. The (size_t) -2 behavior (consuming the input bytes) matches
what is specified in ISO C11.
(cherry picked from commit cf138b0c83)
(cherry picked from commit 690c3475f1)
When there is no login uid Linux sets /proc/self/loginid to the sentinel
value of, (uid_t) -1. If this is set we can return early and avoid
needlessly looking up the sentinel value in any configured nss
databases.
Checked on aarch64-linux-gnu.
* sysdeps/unix/sysv/linux/getlogin_r.c (__getlogin_r_loginuid): Return
early when linux sentinel value is set.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
(cherry picked from commit cc8a1620eb)
Bug 17343 reports that stdlib/random_r.c has code with undefined
behavior because of signed integer overflow on int32_t. This patch
changes the code so that the possibly overflowing computations use
unsigned arithmetic instead.
Note that the bug report refers to "Most code" in that file. The
places changed in this patch are the only ones I found where I think
such overflow can occur.
Tested for x86_64 and x86.
[BZ #17343]
* stdlib/random_r.c (__random_r): Use unsigned arithmetic for
possibly overflowing computations.
(cherry picked from commit 8a07b0c43c)
This simple test uses sigaction to define a signal handler. It then
uses sigaction again to fetch the information about the same signal
handler, and check that they are consistent. This is enough to detect
mismatches between struct kernel_sigaction and the kernel version of
struct sigaction, like in BZ #23069.
Changelog:
* signal/tst-sigaction.c: New file to test BZ #23069.
* signal/Makefile (tests): Fix indentation. Add tst-sigaction.
(cherry picked from commit 7a6f747871)
The RISC-V kernel doesn't define SA_RESTORER, hence the kernel version
of struct sigaction doesn't have the sa_restorer field. The default
kernel_sigaction.h therefore can't be used.
This patch adds a RISC-V specific version of kernel_sigaction.h to fix
the issue. This fixes for example the libnih testsuite.
Note that this patch is not needed in master as the bug has been fixed
by commit b4a5d26d88 ("linux: Consolidate sigaction implementation").
