about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
...
* aarch64: Optimized memcmp for medium to large sizesSiddhesh Poyarekar2019-09-062-21/+60
| | | | | | | | | | | | | | | This improved memcmp provides a fast path for compares up to 16 bytes and then compares 16 bytes at a time, thus optimizing loads from both sources. The glibc memcmp microbenchmark retains performance (with an error of ~1ns) for smaller compare sizes and reduces up to 31% of execution time for compares up to 4K on the APM Mustang. On Qualcomm Falkor this improves to almost 48%, i.e. it is almost 2x improvement for sizes of 2K and above. * sysdeps/aarch64/memcmp.S: Widen comparison to 16 bytes at a time. (cherry picked from commit 30a81dae5b752f8aa5f96e7f7c341ec57cba3585)
* aarch64: Use the L() macro for labels in memcmpSiddhesh Poyarekar2019-09-062-16/+20
| | | | | | | | The L() macro makes the assembly a bit more readable. * sysdeps/aarch64/memcmp.S: Use L() macro for labels. (cherry picked from commit 84c94d2fd90d84ae7e67657ee8e22c2d1b796f63)
* posix: Fix large mmap64 offset for mips64n32 (BZ#24699)Adhemerval Zanella2019-07-155-5/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fix for BZ#21270 (commit 158d5fa0e19) added a mask to avoid offset larger than 1^44 to be used along __NR_mmap2. However mips64n32 users __NR_mmap, as mips64n64, but still defines off_t as old non-LFS type (other ILP32, such x32, defines off_t being equal to off64_t). This leads to use the same mask meant only for __NR_mmap2 call for __NR_mmap, thus limiting the maximum offset it can use with mmap64. This patch fixes by setting the high mask only for __NR_mmap2 usage. The posix/tst-mmap-offset.c already tests it and also fails for mips64n32. The patch also change the test to check for an arch-specific header that defines the maximum supported offset. Checked on x86_64-linux-gnu, i686-linux-gnu, and I also tests tst-mmap-offset on qemu simulated mips64 with kernel 3.2.0 kernel for both mips-linux-gnu and mips64-n32-linux-gnu. [BZ #24699] * posix/tst-mmap-offset.c: Mention BZ #24699. (do_test_bz21270): Rename to do_test_large_offset and use mmap64_maximum_offset to check for maximum expected offset value. * sysdeps/generic/mmap_info.h: New file. * sysdeps/unix/sysv/linux/mips/mmap_info.h: Likewise. * sysdeps/unix/sysv/linux/mmap64.c (MMAP_OFF_HIGH_MASK): Define iff __NR_mmap2 is used. (cherry picked from commit a008c76b56e4f958cf5a0d6f67d29fade89421b7)
* aarch64: handle STO_AARCH64_VARIANT_PCSSzabolcs Nagy2019-07-122-4/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backport of commit 82bc69c012838a381c4167c156a06f4598f34227 and commit 30ba0375464f34e4bf8129f3d3dc14d0c09add17 without using DT_AARCH64_VARIANT_PCS for optimizing the symbol table check. This is needed so the internal abi between ld.so and libc.so is unchanged. Avoid lazy binding of symbols that may follow a variant PCS with different register usage convention from the base PCS. Currently the lazy binding entry code does not preserve all the registers required for AdvSIMD and SVE vector calls. Saving and restoring all registers unconditionally may break existing binaries, even if they never use vector calls, because of the larger stack requirement for lazy resolution, which can be significant on an SVE system. The solution is to mark all symbols in the symbol table that may follow a variant PCS so the dynamic linker can handle them specially. In this patch such symbols are always resolved at load time, not lazily. So currently LD_AUDIT for variant PCS symbols are not supported, for that the _dl_runtime_profile entry needs to be changed e.g. to unconditionally save/restore all registers (but pass down arg and retval registers to pltentry/exit callbacks according to the base PCS). This patch also removes a __builtin_expect from the modified code because the branch prediction hint did not seem useful. * sysdeps/aarch64/dl-machine.h (elf_machine_lazy_rel): Check STO_AARCH64_VARIANT_PCS and bind such symbols at load time.
* aarch64: add STO_AARCH64_VARIANT_PCS and DT_AARCH64_VARIANT_PCSSzabolcs Nagy2019-07-102-0/+12
| | | | | | | | | | | | | STO_AARCH64_VARIANT_PCS is a non-visibility st_other flag for marking symbols that reference functions that may follow a variant PCS with different register usage convention from the base PCS. DT_AARCH64_VARIANT_PCS is a dynamic tag that marks ELF modules that have R_*_JUMP_SLOT relocations for symbols marked with STO_AARCH64_VARIANT_PCS (i.e. have variant PCS calls via a PLT). * elf/elf.h (STO_AARCH64_VARIANT_PCS): Define. (DT_AARCH64_VARIANT_PCS): Define.
* io: Remove copy_file_range emulation [BZ #24744]Florian Weimer2019-07-0911-777/+77
| | | | | | | | | | | The kernel is evolving this interface (e.g., removal of the restriction on cross-device copies), and keeping up with that is difficult. Applications which need the function should run kernels which support the system call instead of relying on the imperfect glibc emulation. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit 5a659ccc0ec217ab02a4c273a1f6d346a359560a)
* libio: do not attempt to free wide buffers of legacy streams [BZ #24228]Dmitry V. Levin2019-06-206-5/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit a601b74d31ca086de38441d316a3dee24c866305 aka glibc-2.23~693 ("In preparation for fixing BZ#16734, fix failure in misc/tst-error1-mem when _G_HAVE_MMAP is turned off.") introduced a regression: _IO_unbuffer_all now invokes _IO_wsetb to free wide buffers of all files, including legacy standard files which are small statically allocated objects that do not have wide buffers and the _mode member, causing memory corruption. Another memory corruption in _IO_unbuffer_all happens when -1 is assigned to the _mode member of legacy standard files that do not have it. [BZ #24228] * libio/genops.c (_IO_unbuffer_all) [SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_1)]: Do not attempt to free wide buffers and access _IO_FILE_complete members of legacy libio streams. * libio/tst-bz24228.c: New file. * libio/tst-bz24228.map: Likewise. * libio/Makefile [build-shared] (tests): Add tst-bz24228. [build-shared] (generated): Add tst-bz24228.mtrace and tst-bz24228.check. [run-built-tests && build-shared] (tests-special): Add $(objpfx)tst-bz24228-mem.out. (LDFLAGS-tst-bz24228, tst-bz24228-ENV): New variables. ($(objpfx)tst-bz24228-mem.out): New rule. (cherry picked from commit 21cc130b78a4db9113fb6695e2b951e697662440)
* NEWS: add entries for bugs 22964, 24180, and 24531Dmitry V. Levin2019-06-201-0/+4
|
* Fix tcache count maximum (BZ #24531)Wilco Dijkstra2019-05-223-4/+16
| | | | | | | | | | | | | | The tcache counts[] array is a char, which has a very small range and thus may overflow. When setting tcache_count tunable, there is no overflow check. However the tunable must not be larger than the maximum value of the tcache counts[] array, otherwise it can overflow when filling the tcache. [BZ #24531] * malloc/malloc.c (MAX_TCACHE_COUNT): New define. (do_set_tcache_count): Only update if count is small enough. * manual/tunables.texi (glibc.malloc.tcache_count): Document max value. (cherry picked from commit 5ad533e8e65092be962e414e0417112c65d154fb)
* Fix crash in _IO_wfile_sync (bug 20568)Andreas Schwab2019-05-156-3/+56
| | | | | | | | When computing the length of the converted part of the stdio buffer, use the number of consumed wide characters, not the (negative) distance to the end of the wide buffer. (cherry picked from commit 32ff397533715988c19cbf3675dcbd727ec13e18)
* elf: Fix pldd (BZ#18035)Adhemerval Zanella2019-04-264-108/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since 9182aa67994 (Fix vDSO l_name for GDB's, BZ#387) the initial link_map for executable itself and loader will have both l_name and l_libname->name holding the same value due: elf/dl-object.c 95 new->l_name = *realname ? realname : (char *) newname->name + libname_len - 1; Since newname->name points to new->l_libname->name. This leads to pldd to an infinite call at: elf/pldd-xx.c 203 again: 204 while (1) 205 { 206 ssize_t n = pread64 (memfd, tmpbuf.data, tmpbuf.length, name_offset); 228 /* Try the l_libname element. */ 229 struct E(libname_list) ln; 230 if (pread64 (memfd, &ln, sizeof (ln), m.l_libname) == sizeof (ln)) 231 { 232 name_offset = ln.name; 233 goto again; 234 } Since the value at ln.name (l_libname->name) will be the same as previously read. The straightforward fix is just avoid the check and read the new list entry. I checked also against binaries issues with old loaders with fix for BZ#387, and pldd could dump the shared objects. Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu, and powerpc64le-linux-gnu. [BZ #18035] * elf/Makefile (tests-container): Add tst-pldd. * elf/pldd-xx.c: Use _Static_assert in of pldd_assert. (E(find_maps)): Avoid use alloca, use default read file operations instead of explicit LFS names, and fix infinite loop. * elf/pldd.c: Explicit set _FILE_OFFSET_BITS, cleanup headers. (get_process_info): Use _Static_assert instead of assert, use default directory operations instead of explicit LFS names, and free some leadek pointers. * elf/tst-pldd.c: New file. (cherry picked from commit 1a4c27355e146b6d8cc6487b998462c7fdd1048f) (Backported without the test case due to lack of test-in-container support.)
* ja_JP locale: Add entry for the new Japanese era [BZ #22964]TAMUKI Shoichi2019-04-023-1/+11
| | | | | | | | | | | | The Japanese era name will be changed on May 1, 2019. The Japanese government made a preliminary announcement on April 1, 2019. The glibc ja_JP locale must be updated to include the new era name for strftime's alternative year format support. This is a minimal cherry pick of just the required locale changes. (cherry picked from commit 466afec30896585b60c2106df7a722a86247c9f3)
* S390: Mark vx and vxe as important hwcap.Stefan Liebler2019-03-212-1/+7
| | | | | | | | | | | | | This patch adds vx and vxe as important hwcaps which allows one to provide shared libraries tuned for platforms with non-vx/-vxe, vx or vxe. ChangeLog: * sysdeps/s390/dl-procinfo.h (HWCAP_IMPORTANT): Add HWCAP_S390_VX and HWCAP_S390_VXE. (cherry picked from commit 61f5e9470fb397a4c334938ac5a667427d9047df)
* Add compiler barriers around modifications of the robust mutex list for ↵Stefan Liebler2019-02-072-4/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pthread_mutex_trylock. [BZ #24180] While debugging a kernel warning, Thomas Gleixner, Sebastian Sewior and Heiko Carstens found a bug in pthread_mutex_trylock due to misordered instructions: 140: a5 1b 00 01 oill %r1,1 144: e5 48 a0 f0 00 00 mvghi 240(%r10),0 <--- THREAD_SETMEM (THREAD_SELF, robust_head.list_op_pending, NULL); 14a: e3 10 a0 e0 00 24 stg %r1,224(%r10) <--- last THREAD_SETMEM of ENQUEUE_MUTEX_PI vs (with compiler barriers): 140: a5 1b 00 01 oill %r1,1 144: e3 10 a0 e0 00 24 stg %r1,224(%r10) 14a: e5 48 a0 f0 00 00 mvghi 240(%r10),0 Please have a look at the discussion: "Re: WARN_ON_ONCE(!new_owner) within wake_futex_pi() triggerede" (https://lore.kernel.org/lkml/20190202112006.GB3381@osiris/) This patch is introducing the same compiler barriers and comments for pthread_mutex_trylock as introduced for pthread_mutex_lock and pthread_mutex_timedlock by commit 8f9450a0b7a9e78267e8ae1ab1000ebca08e473e "Add compiler barriers around modifications of the robust mutex list." ChangeLog: [BZ #24180] * nptl/pthread_mutex_trylock.c (__pthread_mutex_trylock): Add compiler barriers and comments. (cherry picked from commit 823624bdc47f1f80109c9c52dee7939b9386d708)
* x86-64 memcmp: Use unsigned Jcc instructions on size [BZ #24155]H.J. Lu2019-02-045-9/+113
| | | | | | | | | | | | | | | | | | Since the size argument is unsigned. we should use unsigned Jcc instructions, instead of signed, to check size. Tested on x86-64 and x32, with and without --disable-multi-arch. [BZ #24155] CVE-2019-7309 * NEWS: Updated for CVE-2019-7309. * sysdeps/x86_64/memcmp.S: Use RDX_LP for size. Clear the upper 32 bits of RDX register for x32. Use unsigned Jcc instructions, instead of signed. * sysdeps/x86_64/x32/Makefile (tests): Add tst-size_t-memcmp-2. * sysdeps/x86_64/x32/tst-size_t-memcmp-2.c: New test. (cherry picked from commit 3f635fb43389b54f682fc9ed2acc0b2aaf4a923d)
* x86-64 strnlen/wcsnlen: Properly handle the length parameter [BZ #24097]H.J. Lu2019-02-016-11/+118
| | | | | | | | | | | | | | | | | | | | | | | On x32, the size_t parameter may be passed in the lower 32 bits of a 64-bit register with the non-zero upper 32 bits. The string/memory functions written in assembly can only use the lower 32 bits of a 64-bit register as length or must clear the upper 32 bits before using the full 64-bit register for length. This pach fixes strnlen/wcsnlen for x32. Tested on x86-64 and x32. On x86-64, libc.so is the same with and withou the fix. [BZ #24097] CVE-2019-6488 * sysdeps/x86_64/multiarch/strlen-avx2.S: Use RSI_LP for length. Clear the upper 32 bits of RSI register. * sysdeps/x86_64/strlen.S: Use RSI_LP for length. * sysdeps/x86_64/x32/Makefile (tests): Add tst-size_t-strnlen and tst-size_t-wcsnlen. * sysdeps/x86_64/x32/tst-size_t-strnlen.c: New file. * sysdeps/x86_64/x32/tst-size_t-wcsnlen.c: Likewise. (cherry picked from commit 5165de69c0908e28a380cbd4bb054e55ea4abc95)
* x86-64 strncpy: Properly handle the length parameter [BZ #24097]H.J. Lu2019-02-015-6/+74
| | | | | | | | | | | | | | | | | | | | | On x32, the size_t parameter may be passed in the lower 32 bits of a 64-bit register with the non-zero upper 32 bits. The string/memory functions written in assembly can only use the lower 32 bits of a 64-bit register as length or must clear the upper 32 bits before using the full 64-bit register for length. This pach fixes strncpy for x32. Tested on x86-64 and x32. On x86-64, libc.so is the same with and withou the fix. [BZ #24097] CVE-2019-6488 * sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S: Use RDX_LP for length. * sysdeps/x86_64/multiarch/strcpy-ssse3.S: Likewise. * sysdeps/x86_64/x32/Makefile (tests): Add tst-size_t-strncpy. * sysdeps/x86_64/x32/tst-size_t-strncpy.c: New file. (cherry picked from commit c7c54f65b080affb87a1513dee449c8ad6143c8b)
* x86-64 strncmp family: Properly handle the length parameter [BZ #24097]H.J. Lu2019-02-017-8/+179
| | | | | | | | | | | | | | | | | | | | | | | On x32, the size_t parameter may be passed in the lower 32 bits of a 64-bit register with the non-zero upper 32 bits. The string/memory functions written in assembly can only use the lower 32 bits of a 64-bit register as length or must clear the upper 32 bits before using the full 64-bit register for length. This pach fixes the strncmp family for x32. Tested on x86-64 and x32. On x86-64, libc.so is the same with and withou the fix. [BZ #24097] CVE-2019-6488 * sysdeps/x86_64/multiarch/strcmp-sse42.S: Use RDX_LP for length. * sysdeps/x86_64/strcmp.S: Likewise. * sysdeps/x86_64/x32/Makefile (tests): Add tst-size_t-strncasecmp, tst-size_t-strncmp and tst-size_t-wcsncmp. * sysdeps/x86_64/x32/tst-size_t-strncasecmp.c: New file. * sysdeps/x86_64/x32/tst-size_t-strncmp.c: Likewise. * sysdeps/x86_64/x32/tst-size_t-wcsncmp.c: Likewise. (cherry picked from commit ee915088a0231cd421054dbd8abab7aadf331153)
* x86-64 memset/wmemset: Properly handle the length parameter [BZ #24097]H.J. Lu2019-02-016-15/+131
| | | | | | | | | | | | | | | | | | | | | | On x32, the size_t parameter may be passed in the lower 32 bits of a 64-bit register with the non-zero upper 32 bits. The string/memory functions written in assembly can only use the lower 32 bits of a 64-bit register as length or must clear the upper 32 bits before using the full 64-bit register for length. This pach fixes memset/wmemset for x32. Tested on x86-64 and x32. On x86-64, libc.so is the same with and withou the fix. [BZ #24097] CVE-2019-6488 * sysdeps/x86_64/multiarch/memset-avx512-no-vzeroupper.S: Use RDX_LP for length. Clear the upper 32 bits of RDX register. * sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S: Likewise. * sysdeps/x86_64/x32/Makefile (tests): Add tst-size_t-wmemset. * sysdeps/x86_64/x32/tst-size_t-memset.c: New file. * sysdeps/x86_64/x32/tst-size_t-wmemset.c: Likewise. (cherry picked from commit 82d0b4a4d76db554eb6757acb790fcea30b19965)
* x86-64 memrchr: Properly handle the length parameter [BZ #24097]H.J. Lu2019-02-015-5/+72
| | | | | | | | | | | | | | | | | | | | On x32, the size_t parameter may be passed in the lower 32 bits of a 64-bit register with the non-zero upper 32 bits. The string/memory functions written in assembly can only use the lower 32 bits of a 64-bit register as length or must clear the upper 32 bits before using the full 64-bit register for length. This pach fixes memrchr for x32. Tested on x86-64 and x32. On x86-64, libc.so is the same with and withou the fix. [BZ #24097] CVE-2019-6488 * sysdeps/x86_64/memrchr.S: Use RDX_LP for length. * sysdeps/x86_64/multiarch/memrchr-avx2.S: Likewise. * sysdeps/x86_64/x32/Makefile (tests): Add tst-size_t-memrchr. * sysdeps/x86_64/x32/tst-size_t-memrchr.c: New file. (cherry picked from commit ecd8b842cf37ea112e59cd9085ff1f1b6e208ae0)
* x86-64 memcpy: Properly handle the length parameter [BZ #24097]H.J. Lu2019-02-017-40/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | On x32, the size_t parameter may be passed in the lower 32 bits of a 64-bit register with the non-zero upper 32 bits. The string/memory functions written in assembly can only use the lower 32 bits of a 64-bit register as length or must clear the upper 32 bits before using the full 64-bit register for length. This pach fixes memcpy for x32. Tested on x86-64 and x32. On x86-64, libc.so is the same with and withou the fix. [BZ #24097] CVE-2019-6488 * sysdeps/x86_64/multiarch/memcpy-ssse3-back.S: Use RDX_LP for length. Clear the upper 32 bits of RDX register. * sysdeps/x86_64/multiarch/memcpy-ssse3.S: Likewise. * sysdeps/x86_64/multiarch/memmove-avx512-no-vzeroupper.S: Likewise. * sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Likewise. * sysdeps/x86_64/x32/Makefile (tests): Add tst-size_t-memcpy. tst-size_t-wmemchr. * sysdeps/x86_64/x32/tst-size_t-memcpy.c: New file. (cherry picked from commit 231c56760c1e2ded21ad96bbb860b1f08c556c7a)
* x86-64 memcmp/wmemcmp: Properly handle the length parameter [BZ #24097]H.J. Lu2019-02-017-9/+127
| | | | | | | | | | | | | | | | | | | | | | | | On x32, the size_t parameter may be passed in the lower 32 bits of a 64-bit register with the non-zero upper 32 bits. The string/memory functions written in assembly can only use the lower 32 bits of a 64-bit register as length or must clear the upper 32 bits before using the full 64-bit register for length. This pach fixes memcmp/wmemcmp for x32. Tested on x86-64 and x32. On x86-64, libc.so is the same with and withou the fix. [BZ #24097] CVE-2019-6488 * sysdeps/x86_64/multiarch/memcmp-avx2-movbe.S: Use RDX_LP for length. Clear the upper 32 bits of RDX register. * sysdeps/x86_64/multiarch/memcmp-sse4.S: Likewise. * sysdeps/x86_64/multiarch/memcmp-ssse3.S: Likewise. * sysdeps/x86_64/x32/Makefile (tests): Add tst-size_t-memcmp and tst-size_t-wmemcmp. * sysdeps/x86_64/x32/tst-size_t-memcmp.c: New file. * sysdeps/x86_64/x32/tst-size_t-wmemcmp.c: Likewise. (cherry picked from commit b304fc201d2f6baf52ea790df8643e99772243cd)
* x86-64 memchr/wmemchr: Properly handle the length parameter [BZ #24097]H.J. Lu2019-02-018-5/+168
| | | | | | | | | | | | | | | | | | | | | | | | On x32, the size_t parameter may be passed in the lower 32 bits of a 64-bit register with the non-zero upper 32 bits. The string/memory functions written in assembly can only use the lower 32 bits of a 64-bit register as length or must clear the upper 32 bits before using the full 64-bit register for length. This pach fixes memchr/wmemchr for x32. Tested on x86-64 and x32. On x86-64, libc.so is the same with and withou the fix. [BZ #24097] CVE-2019-6488 * sysdeps/x86_64/memchr.S: Use RDX_LP for length. Clear the upper 32 bits of RDX register. * sysdeps/x86_64/multiarch/memchr-avx2.S: Likewise. * sysdeps/x86_64/x32/Makefile (tests): Add tst-size_t-memchr and tst-size_t-wmemchr. * sysdeps/x86_64/x32/test-size_t.h: New file. * sysdeps/x86_64/x32/tst-size_t-memchr.c: Likewise. * sysdeps/x86_64/x32/tst-size_t-wmemchr.c: Likewise. (cherry picked from commit 97700a34f36721b11a754cf37a1cc40695ece1fd)
* NEWS: add entries for bugs 23275, 23861, and 23907Dmitry V. Levin2019-01-061-0/+3
|
* intl: Do not return NULL on asprintf failure in gettext [BZ #24018]Florian Weimer2019-01-023-1/+8
| | | | | | | Fixes commit 9695dd0c9309712ed8e9c17a7040fe7af347f2dc ("DCIGETTEXT: Use getcwd, asprintf to construct absolute pathname"). (cherry picked from commit 8c1aafc1f34d090a5b41dc527c33e8687f6a1287)
* malloc: Always call memcpy in _int_realloc [BZ #24027]Florian Weimer2019-01-013-42/+9
| | | | | | | | | | This commit removes the custom memcpy implementation from _int_realloc for small chunk sizes. The ncopies variable has the wrong type, and an integer wraparound could cause the existing code to copy too few elements (leaving the new memory region mostly uninitialized). Therefore, removing this code fixes bug 24027. (cherry picked from commit b50dd3bc8cbb1efe85399b03d7e6c0310c2ead84)
* Fix rwlock stall with PREFER_WRITER_NONRECURSIVE_NP (bug 23861)Andreas Schwab2018-12-134-3/+100
| | | | | | | | | | | | In the read lock function (__pthread_rwlock_rdlock_full) there was a code path which would fail to reload __readers while waiting for PTHREAD_RWLOCK_RWAITING to change. This failure to reload __readers into a local value meant that various conditionals used the old value of __readers and with only two threads left it could result in an indefinite stall of one of the readers (waiting for PTHREAD_RWLOCK_RWAITING to go to zero, but it never would). (cherry picked from commit f21e8f8ca466320fed38bdb71526c574dae98026)
* powerpc: Add missing CFI register information (bug #23614)Tulio Magno Quites Machado Filho2018-12-135-18/+47
| | | | | | | | | | | | | | | Add CFI information about the offset of registers stored in the stack frame. [BZ #23614] * sysdeps/powerpc/powerpc64/addmul_1.S (FUNC): Add CFI offset for registers saved in the stack frame. * sysdeps/powerpc/powerpc64/lshift.S (__mpn_lshift): Likewise. * sysdeps/powerpc/powerpc64/mul_1.S (__mpn_mul_1): Likewise. Signed-off-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com> Reviewed-by: Gabriel F. T. Gomes <gabriel@inconstante.eti.br> (cherry picked from commit 1d880d4a9bf7608c2cd33bbe954ce6995f79121a)
* Fix _dl_profile_fixup data-dependency issue (Bug 23690)Tulio Magno Quites Machado Filho2018-12-139-7/+360
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a data-dependency between the fields of struct l_reloc_result and the field used as the initialization guard. Users of the guard expect writes to the structure to be observable when they also observe the guard initialized. The solution for this problem is to use an acquire and release load and store to ensure previous writes to the structure are observable if the guard is initialized. The previous implementation used DL_FIXUP_VALUE_ADDR (l_reloc_result->addr) as the initialization guard, making it impossible for some architectures to load and store it atomically, i.e. hppa and ia64, due to its larger size. This commit adds an unsigned int to l_reloc_result to be used as the new initialization guard of the struct, making it possible to load and store it atomically in all architectures. The fix ensures that the values observed in l_reloc_result are consistent and do not lead to crashes. The algorithm is documented in the code in elf/dl-runtime.c (_dl_profile_fixup). Not all data races have been eliminated. Tested with build-many-glibcs and on powerpc, powerpc64, and powerpc64le. [BZ #23690] * elf/dl-runtime.c (_dl_profile_fixup): Guarantee memory modification order when accessing reloc_result->addr. * include/link.h (reloc_result): Add field init. * nptl/Makefile (tests): Add tst-audit-threads. (modules-names): Add tst-audit-threads-mod1 and tst-audit-threads-mod2. Add rules to build tst-audit-threads. * nptl/tst-audit-threads-mod1.c: New file. * nptl/tst-audit-threads-mod2.c: Likewise. * nptl/tst-audit-threads.c: Likewise. * nptl/tst-audit-threads.h: Likewise. Signed-off-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit e5d262effe3a87164308a3f37e61b32d0348692a)
* inet/tst-if_index-long: New test case for CVE-2018-19591 [BZ #23927]Florian Weimer2018-12-123-1/+69
| | | | (cherry picked from commit 899478c2bfa00c5df8d8bedb52effbb065700278)
* support: Implement <support/descriptors.h> to track file descriptorsFlorian Weimer2018-12-127-0/+544
| | | | (cherry picked from commit f255336a9301619519045548acb2e1027065a837)
* support: Close original descriptors in support_capture_subprocessFlorian Weimer2018-12-122-0/+12
| | | | (cherry picked from commit 02cd5c1a8d033d7f91fea12a66bb44d1bbf85f76)
* support_quote_string: Do not use str parameter nameFlorian Weimer2018-12-122-2/+7
| | | | | | | This avoids a build failure if this identifier is used as a macro in a test. (cherry picked from commit 47d8d9a2172f827a8dde7695f415aa6f78a82d0e)
* support: Implement support_quote_stringFlorian Weimer2018-12-125-0/+102
| | | | | Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> (cherry picked from commit c74a91deaa5de416237c02bbb3e41bda76ca4c7b)
* malloc: Add another test for tcache double free check.DJ Delorie2018-12-123-1/+63
| | | | | | | | | | | | This one tests for BZ#23907 where the double free test didn't check the tcache bin bounds before dereferencing the bin. [BZ #23907] * malloc/tst-tcfree3.c: New. * malloc/Makefile: Add it. (cherry picked from commit 7c9a7c68363051cfc5fa1ebb96b3b2c1f82dcb76)
* malloc: tcache double free checkDJ Delorie2018-12-127-7/+161
| | | | | | | | | | | | | | | | | | | | | | | * malloc/malloc.c (tcache_entry): Add key field. (tcache_put): Set it. (tcache_get): Likewise. (_int_free): Check for double free in tcache. * malloc/tst-tcfree1.c: New. * malloc/tst-tcfree2.c: New. * malloc/Makefile: Run the new tests. * manual/probes.texi: Document memory_tcache_double_free probe. * dlfcn/dlerror.c (check_free): Prevent double frees. (cherry picked from commit bcdaad21d4635931d1bd3b54a7894276925d081d) malloc: tcache: Validate tc_idx before checking for double-frees [BZ #23907] The previous check could read beyond the end of the tcache entry array. If the e->key == tcache cookie check happened to pass, this would result in crashes. (cherry picked from commit affec03b713c82c43a5b025dddc21bde3334f41e)
* CVE-2018-19591: if_nametoindex: Fix descriptor for overlong name [BZ #23927]Florian Weimer2018-11-273-5/+18
| | | | (cherry picked from commit d527c860f5a3f0ed687bd03f0cb464612dc23408)
* Add an additional test to resolv/tst-resolv-network.cAlexandra Hájková2018-11-092-0/+11
| | | | | | Test for the infinite loop in getnetbyname, bug #17630. (cherry picked from commit ac8060265bcaca61568ef3a20b9a0140a270af54)
* libanl: properly cleanup if first helper thread creation failed (bug 22927)Andreas Schwab2018-11-063-2/+12
| | | | (cherry picked from commit bd3b0fbae33a9a4cc5e2daf049443d5cf03d4251)
* x86: Fix Haswell CPU string flags (BZ#23709)Adhemerval Zanella2018-11-023-0/+13
| | | | | | | | | | | | | | | | | | | | | Th commit 'Disable TSX on some Haswell processors.' (2702856bf4) changed the default flags for Haswell models. Previously, new models were handled by the default switch path, which assumed a Core i3/i5/i7 if AVX is available. After the patch, Haswell models (0x3f, 0x3c, 0x45, 0x46) do not set the flags Fast_Rep_String, Fast_Unaligned_Load, Fast_Unaligned_Copy, and Prefer_PMINUB_for_stringop (only the TSX one). This patch fixes it by disentangle the TSX flag handling from the memory optimization ones. The strstr case cited on patch now selects the __strstr_sse2_unaligned as expected for the Haswell cpu. Checked on x86_64-linux-gnu. [BZ #23709] * sysdeps/x86/cpu-features.c (init_cpu_features): Set TSX bits independently of other flags. (cherry picked from commit c3d8dc45c9df199b8334599a6cbd98c9950dba62)
* i64: fix missing exp2f, log2f and powf symbols in libm.a [BZ #23822]Szabolcs Nagy2018-10-265-9/+17
| | | | | | | | | | | | | | | | | | | | | | | When new symbol versions were introduced without SVID compatible error handling the exp2f, log2f and powf symbols were accidentally removed from the ia64 lim.a. The regression was introduced by the commits f5f0f5265162fe6f4f238abcd3086985f7c38d6d New expf and exp2f version without SVID compat wrapper 72d3d281080be9f674982067d72874fd6cdb4b64 New symbol version for logf, log2f and powf without SVID compat With WEAK_LIBM_ENTRY(foo), there is a hidden __foo and weak foo symbol definition in both SHARED and !SHARED build. [BZ #23822] * sysdeps/ia64/fpu/e_exp2f.S (exp2f): Use WEAK_LIBM_ENTRY. * sysdeps/ia64/fpu/e_log2f.S (log2f): Likewise. * sysdeps/ia64/fpu/e_exp2f.S (powf): Likewise. (cherry picked from commit ba5b14c7613980dfefcad6b6e88f913e5f596c59)
* conform: XFAIL siginfo_t si_band test on sparc64Florian Weimer2018-10-266-3/+29
| | | | | | | 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 7c5e34d7f1b8f8f5acd94c2b885ae13b85414dcd)
* signal: Use correct type for si_band in siginfo_t [BZ #23562]Ilya Yu. Malakhov2018-10-223-1/+8
| | | | (cherry picked from commit f997b4be18f7e57d757d39e42f7715db26528aa0)
* Fix race in pthread_mutex_lock while promoting to PTHREAD_MUTEX_ELISION_NP ↵Stefan Liebler2018-10-1817-50/+386
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [BZ #23275] 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 403b4feb22dcbc85ace72a361d2a951380372471)
* Fix misreported errno on preadv2/pwritev2 (BZ#23579)Adhemerval Zanella2018-09-289-7/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 7a16bdbb9ff4122af0a28dc20996c95352011fdd)
* preadv2/pwritev2: Handle offset == -1 [BZ #22753]Florian Weimer2018-09-2814-15/+105
| | | | | | Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit d4b4a00a462348750bb18544eb30853ee6ac5d10)
* Fix segfault in maybe_script_execute.Stefan Liebler2018-09-102-1/+6
| | | | | | | | | | | | | | | | | | | 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 28669f86f6780a18daca264f32d66b1428c9c6f1)
* pthread_cond_broadcast: Fix waiters-after-spinning case [BZ #23538]Martin Kuchta2018-08-273-2/+15
| | | | (cherry picked from commit 99ea93ca31795469d2a1f1570f17a5c39c2eb7e2)
* x86: Populate COMMON_CPUID_INDEX_80000001 for Intel CPUs [BZ #23459]H.J. Lu2018-07-294-10/+30
| | | | | | | | | | | | | | Reviewed-by: Carlos O'Donell <carlos@redhat.com> [BZ #23459] * sysdeps/x86/cpu-features.c (get_extended_indices): New function. (init_cpu_features): Call get_extended_indices for both Intel and AMD CPUs. * sysdeps/x86/cpu-features.h (COMMON_CPUID_INDEX_80000001): Remove "for AMD" comment. (cherry picked from commit be525a69a6630abc83144c0a96474f2e26da7443)
* x86: Correct index_cpu_LZCNT [BZ #23456]H.J. Lu2018-07-293-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 65d87ade1ee6f3ac099105e3511bd09bdc24cf3f)