about summary refs log tree commit diff
path: root/NEWS
Commit message (Collapse)AuthorAgeFilesLines
* NEWS: Add entry for CVE-2021-27645DJ Delorie2021-03-091-1/+4
|
* ld.so: Implement the --list-diagnostics optionFlorian Weimer2021-03-021-0/+4
|
* NEWS: Add missing bug closuresSamuel Thibault2021-02-231-5/+6
|
* linux: Require /dev/shm as the shared memory file systemFlorian Weimer2021-02-081-1/+4
| | | | | | | | | | | | | | | | | | | | | Previously, glibc would pick an arbitrary tmpfs file system from /proc/mounts if /dev/shm was not available. This could lead to an unsuitable file system being picked for the backing storage for shm_open, sem_open, and related functions. This patch introduces a new function, __shm_get_name, which builds the file name under the appropriate (now hard-coded) directory. It is called from the various shm_* and sem_* function. Unlike the SHM_GET_NAME macro it replaces, the callers handle the return values and errno updates. shm-directory.c is moved directly into the posix subdirectory because it can be implemented directly using POSIX functionality. It resides in libc because it is needed by both librt and nptl/htl. In the sem_open implementation, tmpfname is initialized directly from a string constant. This happens to remove one alloca call. Checked on x86_64-linux-gnu.
* Move _SC_MINSIGSTKSZ/_SC_SIGSTKSZ entry in NEWSH.J. Lu2021-02-011-6/+4
| | | | Move _SC_MINSIGSTKSZ/_SC_SIGSTKSZ entry to 2.34 section.
* sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305]H.J. Lu2021-02-011-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add _SC_MINSIGSTKSZ for the minimum signal stack size derived from AT_MINSIGSTKSZ, which is the minimum number of bytes of free stack space required in order to gurantee successful, non-nested handling of a single signal whose handler is an empty function, and _SC_SIGSTKSZ which is the suggested minimum number of bytes of stack space required for a signal stack. If AT_MINSIGSTKSZ isn't available, sysconf (_SC_MINSIGSTKSZ) returns MINSIGSTKSZ. On Linux/x86 with XSAVE, the signal frame used by kernel is composed of the following areas and laid out as: ------------------------------ | alignment padding | ------------------------------ | xsave buffer | ------------------------------ | fsave header (32-bit only) | ------------------------------ | siginfo + ucontext | ------------------------------ Compute AT_MINSIGSTKSZ value as size of xsave buffer + size of fsave header (32-bit only) + size of siginfo and ucontext + alignment padding. If _SC_SIGSTKSZ_SOURCE or _GNU_SOURCE are defined, MINSIGSTKSZ and SIGSTKSZ are redefined as /* Default stack size for a signal handler: sysconf (SC_SIGSTKSZ). */ # undef SIGSTKSZ # define SIGSTKSZ sysconf (_SC_SIGSTKSZ) /* Minimum stack size for a signal handler: SIGSTKSZ. */ # undef MINSIGSTKSZ # define MINSIGSTKSZ SIGSTKSZ Compilation will fail if the source assumes constant MINSIGSTKSZ or SIGSTKSZ. The reason for not simply increasing the kernel's MINSIGSTKSZ #define (apart from the fact that it is rarely used, due to glibc's shadowing definitions) was that userspace binaries will have baked in the old value of the constant and may be making assumptions about it. For example, the type (char [MINSIGSTKSZ]) changes if this #define changes. This could be a problem if an newly built library tries to memcpy() or dump such an object defined by and old binary. Bounds-checking and the stack sizes passed to things like sigaltstack() and makecontext() could similarly go wrong.
* Open master branch for glibc 2.34 development glibc-2.33.9000Adhemerval Zanella2021-02-011-0/+24
|
* Update NEWS with bugsAdhemerval Zanella2021-02-011-2/+118
|
* NEWS: Fix typo in CVE-2021-3326 entryFlorian Weimer2021-01-291-1/+1
|
* NEWS: Mention CVE-2021-3326 (iconv assertion with ISO-20220-JP-3)Florian Weimer2021-01-291-0/+6
|
* NEWS: Add entry for glibc-hwcaps and deprecate legacy hwcapsFlorian Weimer2021-01-291-0/+21
|
* ld.so: Add --list-tunables to print tunable valuesH.J. Lu2021-01-151-0/+4
| | | | | | Pass --list-tunables to ld.so to print tunables with min and max values. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Update NEWS for CVE-2019-25013.Siddhesh Poyarekar2021-01-081-0/+3
|
* Update copyright dates not handled by scripts/update-copyrights.Paul Eggert2021-01-021-3/+1
| | | | | | | | | | | | | | I've updated copyright dates in glibc for 2021. This is the patch for the changes not generated by scripts/update-copyrights and subsequent build / regeneration of generated files. As well as the usual annual updates, mainly dates in --version output (minus csu/version.c which previously had to be handled manually but is now successfully updated by update-copyrights), there is a small change to the copyright notice in NEWS which should let NEWS get updated automatically next year. Please remember to include 2021 in the dates for any new files added in future (which means updating any existing uncommitted patches you have that add new files to use the new copyright dates in them).
* Update copyright dates with scripts/update-copyrightsPaul Eggert2021-01-021-1/+1
| | | | | | | | | | | | | | | | I used these shell commands: ../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright (cd ../glibc && git commit -am"[this commit message]") and then ignored the output, which consisted lines saying "FOO: warning: copyright statement not found" for each of 6694 files FOO. I then removed trailing white space from benchtests/bench-pthread-locks.c and iconvdata/tst-iconv-big5-hkscs-to-2ucs4.c, to work around this diagnostic from Savannah: remote: *** pre-commit check failed ... remote: *** error: lines with trailing whitespace found remote: error: hook declined to update refs/heads/master
* Introduce _FORTIFY_SOURCE=3Siddhesh Poyarekar2020-12-311-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new _FORTIFY_SOURCE level of 3 to enable additional fortifications that may have a noticeable performance impact, allowing more fortification coverage at the cost of some performance. With llvm 9.0 or later, this will replace the use of __builtin_object_size with __builtin_dynamic_object_size. __builtin_dynamic_object_size ----------------------------- __builtin_dynamic_object_size is an LLVM builtin that is similar to __builtin_object_size. In addition to what __builtin_object_size does, i.e. replace the builtin call with a constant object size, __builtin_dynamic_object_size will replace the call site with an expression that evaluates to the object size, thus expanding its applicability. In practice, __builtin_dynamic_object_size evaluates these expressions through malloc/calloc calls that it can associate with the object being evaluated. A simple motivating example is below; -D_FORTIFY_SOURCE=2 would miss this and emit memcpy, but -D_FORTIFY_SOURCE=3 with the help of __builtin_dynamic_object_size is able to emit __memcpy_chk with the allocation size expression passed into the function: void *copy_obj (const void *src, size_t alloc, size_t copysize) { void *obj = malloc (alloc); memcpy (obj, src, copysize); return obj; } Limitations ----------- If the object was allocated elsewhere that the compiler cannot see, or if it was allocated in the function with a function that the compiler does not recognize as an allocator then __builtin_dynamic_object_size also returns -1. Further, the expression used to compute object size may be non-trivial and may potentially incur a noticeable performance impact. These fortifications are hence enabled at a new _FORTIFY_SOURCE level to allow developers to make a choice on the tradeoff according to their environment.
* s390x: Require GCC 7.1 or later to build glibc.Stefan Liebler2020-12-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | GCC 6.5 fails to correctly build ldconfig with recent ld.so.cache commits, e.g.: 785969a047ad2f23f758901c6816422573544453 elf: Implement a string table for ldconfig, with tail merging If glibc is build with gcc 6.5.0: __builtin_add_overflow is used in <glibc>/elf/stringtable.c:stringtable_finalize() which leads to ldconfig failing with "String table is too large". This is also recognizable in following tests: FAIL: elf/tst-glibc-hwcaps-cache FAIL: elf/tst-glibc-hwcaps-prepend-cache FAIL: elf/tst-ldconfig-X FAIL: elf/tst-ldconfig-bad-aux-cache FAIL: elf/tst-ldconfig-ld_so_conf-update FAIL: elf/tst-stringtable See gcc "Bug 98269 - gcc 6.5.0 __builtin_add_overflow() with small uint32_t values incorrectly detects overflow" (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98269)
* S390: Derive float_t from FLT_EVAL_METHODMarius Hillenbrand2020-12-091-0/+7
| | | | | | | | | | | | | | | | | | float_t supposedly represents the type that is used to evaluate float expressions internally. While the isa supports single-precision float operations, the port of glibc to s390 incorrectly deferred to the generic definitions which, back then, tied float_t to double. gcc by default evaluates float in single precision, so that scenario violates the C standard (sections 5.2.4.2.2 and 7.12 in C11/C17). With -fexcess-precision=standard, gcc evaluates float in double precision, which aligns with the standard yet at the cost of added conversion instructions. With this patch, we drop the s390-specific definition of float_t and defer to the default behavior, which aligns float_t with the compiler-defined FLT_EVAL_METHOD in a standard-compliant way. Checked on s390x-linux-gnu with 31-bit and 64-bit builds.
* Fixed typos in "NEWS for version 2.32"Paul Zimmermann2020-12-081-10/+10
|
* Add NEWS entry for CVE-2020-29562 (BZ #26923)Siddhesh Poyarekar2020-12-081-0/+3
| | | | BZ #26923 now has a CVE entry, so add a NEWS entry for it.
* Fix typo in NEWS fileShuo Wang2020-11-301-3/+3
|
* NEWS entry for commit b4f020c9b408fb3d1d3d4901c4a71839145f8791Florian Weimer2020-11-251-0/+4
|
* iconv: Accept redundant shift sequences in IBM1364 [BZ #26224]Arjun Shankar2020-11-041-1/+3
| | | | | | | | | | | | | | | The IBM1364, IBM1371, IBM1388, IBM1390 and IBM1399 character sets share converter logic (iconvdata/ibm1364.c) which would reject redundant shift sequences when processing input in these character sets. This led to a hang in the iconv program (CVE-2020-27618). This commit adjusts the converter to ignore redundant shift sequences and adds test cases for iconv_prog hangs that would be triggered upon their rejection. This brings the implementation in line with other converters that also ignore redundant shift sequences (e.g. IBM930 etc., fixed in commit 692de4b3960d). Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Remove NEWS entry about ftime removalAdhemerval Zanella2020-10-271-5/+0
| | | | Now that it was reinstate with 30a0b167d3.
* Fix typo in NEWS fileJonathan Wakely2020-10-261-1/+1
|
* Move vtimes to a compatibility symbolAdhemerval Zanella2020-10-191-0/+5
| | | | | | | | | | | | | | I couldn't pinpoint which standard has added it, but no other POSIX system supports it and/or no longer provide it. The 'struct vtimes' also has a lot of drawbacks due its limited internal type size. I couldn't also see find any project that actually uses this symbol, either in some dignostic way (such as sanitizer). So I think it should be safer to just move to compat symbol, instead of deprecated. The idea it to avoid new ports to export such broken interface (riscv32 for instance). Checked on x86_64-linux-gnu and i686-linux-gnu.
* Add NEWS entry for ftime compatibility moveAdhemerval Zanella2020-10-161-0/+5
|
* elf: Do not search HWCAP subdirectories in statically linked binariesFlorian Weimer2020-10-071-0/+4
| | | | | | | | | This functionality does not seem to be useful since static dlopen is mostly used for iconv/character set conversion and NSS support. gconv modules are loaded with full paths anyway, so that the HWCAP subdirectory logic does not apply. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Linux: Require properly configured /dev/pts for PTYsFlorian Weimer2020-10-071-1/+11
| | | | | | | | | | | | | Current systems do not have BSD terminals, so the fallback code in posix_openpt/getpt does not do anything. Also remove the file system check for /dev/pts. Current systems always have a devpts file system mounted there if /dev/ptmx exists. grantpt is now essentially a no-op. It only verifies that the argument is a ptmx-descriptor. Therefore, this change indirectly addresses bug 24941. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* ld.so: add an --argv0 option [BZ #16124]Vincent Mihalkovic2020-09-291-0/+3
|
* Update mallinfo2 ABI, and testDJ Delorie2020-09-171-1/+6
| | | | | | | This patch adds the ABI-related bits to reflect the new mallinfo2 function, and adds a test case to verify basic functionality. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* x86: Install <sys/platform/x86.h> [BZ #26124]H.J. Lu2020-09-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Install <sys/platform/x86.h> so that programmers can do #if __has_include(<sys/platform/x86.h>) #include <sys/platform/x86.h> #endif ... if (CPU_FEATURE_USABLE (SSE2)) ... if (CPU_FEATURE_USABLE (AVX2)) ... <sys/platform/x86.h> exports only: enum { COMMON_CPUID_INDEX_1 = 0, COMMON_CPUID_INDEX_7, COMMON_CPUID_INDEX_80000001, COMMON_CPUID_INDEX_D_ECX_1, COMMON_CPUID_INDEX_80000007, COMMON_CPUID_INDEX_80000008, COMMON_CPUID_INDEX_7_ECX_1, /* Keep the following line at the end. */ COMMON_CPUID_INDEX_MAX }; struct cpuid_features { struct cpuid_registers cpuid; struct cpuid_registers usable; }; struct cpu_features { struct cpu_features_basic basic; struct cpuid_features features[COMMON_CPUID_INDEX_MAX]; }; /* Get a pointer to the CPU features structure. */ extern const struct cpu_features *__x86_get_cpu_features (unsigned int max) __attribute__ ((const)); Since all feature checks are done through macros, programs compiled with a newer <sys/platform/x86.h> are compatible with the older glibc binaries as long as the layout of struct cpu_features is identical. The features array can be expanded with backward binary compatibility for both .o and .so files. When COMMON_CPUID_INDEX_MAX is increased to support new processor features, __x86_get_cpu_features in the older glibc binaries returns NULL and HAS_CPU_FEATURE/CPU_FEATURE_USABLE return false on the new processor feature. No new symbol version is neeeded. Both CPU_FEATURE_USABLE and HAS_CPU_FEATURE are provided. HAS_CPU_FEATURE can be used to identify processor features. Note: Although GCC has __builtin_cpu_supports, it only supports a subset of <sys/platform/x86.h> and it is equivalent to CPU_FEATURE_USABLE. It doesn't support HAS_CPU_FEATURE.
* Documentation for the RISC-V 32-bit portAlistair Francis2020-08-271-1/+10
| | | | | | | There is already RISC-V 64-bit port information in the documentation. Let's add some documentation entries for the RISC-V 32-bit as well. Reviewed-by: Maciej W. Rozycki <macro@wdc.com>
* Open master branch for glibc 2.33 development. glibc-2.32.9000Carlos O'Donell2020-08-041-0/+24
| | | | Happy hacking!
* Update NEWS with bugs.Carlos O'Donell2020-08-041-2/+110
|
* aarch64: update NEWS about branch protectionSzabolcs Nagy2020-08-031-1/+3
| | | | | | | | | | | After some discussions it seems the original news was not clear and that it is valid to manually pass the branch protection flags iff GCC target libs are built with them too. The main difference between manually passing the flags and using the configure option is that the latter also makes branch protection the default in GCC which may not be desirable in some cases. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Add NEWS entry for CVE-2016-10228 (bug 19519)Aurelien Jarno2020-08-031-0/+4
|
* Move NEWS entry for CVE-2020-1751 to the 2.31 sectionFlorian Weimer2020-07-311-3/+3
| | | | | | | | It was fixed in commit d93769405996dfc11d216ddbe415946617b5a494 ("Fix array overflow in backtrace on PowerPC (bug 25423)"), which went into glibc 2.31. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* NEWS: Deprecate weak libpthread symbols for single-threaded checksFlorian Weimer2020-07-311-0/+8
| | | | | | Recommend the new __libc_single_thread variable instead. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* NEWS: Deprecate nss_hesiodFlorian Weimer2020-07-311-0/+5
| | | | | | | Storing user databases in DNS, without client-side DNSSEC validation, is problematic from a security point of view. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Linux: Remove rseq supportFlorian Weimer2020-07-161-10/+0
| | | | | | | | | | | | | | | | | | The kernel ABI is not finalized, and there are now various proposals to change the size of struct rseq, which would make the glibc ABI dependent on the version of the kernels used for building glibc. This is of course not acceptable. This reverts commit 48699da1c468543ade14777819bd1b4d652709de ("elf: Support at least 32-byte alignment in static dlopen"), commit 8f4632deb3545b2949cec5454afc3cb21a0024ea ("Linux: rseq registration tests"), commit 6e29cb3f61ff5432c78a1c84b0d9b123a350ab36 ("Linux: Use rseq in sched_getcpu if available"), and commit 0c76fc3c2b346dc5401dc055d97d4279632b0fb3 ("Linux: Perform rseq registration at C startup and thread creation"), resolving the conflicts introduced by the ARC port and the TLS static surplus changes. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Add NEWS entry for CVE-2020-6096 (bug 25620)Aurelien Jarno2020-07-161-0/+5
| | | | Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Remove --enable-obsolete-rpc configure flagPetr Vorel2020-07-131-0/+8
| | | | | | | | | | | | | | | | | | | | | | Sun RPC was removed from glibc. This includes rpcgen program, librpcsvc, and Sun RPC headers. Also test for bug #20790 was removed (test for rpcgen). Backward compatibility for old programs is kept only for architectures and ABIs that have been added in or before version 2.28. libtirpc is mature enough, librpcsvc and rpcgen are provided in rpcsvc-proto project. NOTE: libnsl code depends on Sun RPC (installed libnsl headers use installed Sun RPC headers), thus --enable-obsolete-rpc was a dependency for --enable-obsolete-nsl (removed in a previous commit). The arc ABI list file has to be updated because the port was added with the sunrpc symbols Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* malloc: Deprecate more hook-related functionalityFlorian Weimer2020-07-131-0/+7
| | | | | | | | __morecore, __after_morecore_hook, and __default_morecore had not been deprecated in commit 7d17596c198f11fa85cbcf9587443f262e63b616 ("Mark malloc hook variables as deprecated"), probably by accident. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Documentation for ARC portVineet Gupta2020-07-101-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (a) ABI doc: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/wiki/files/ARCv2_ABI.pdf (b) Programmer's Reference Manual (PRM) : needs a download request to be filled https://www.synopsys.com/dw/ipdir.php?ds=arc-hs44-hs46-hs48 https://www.synopsys.com/dw/doc.php/ds/cc/programmers-reference-manual-ARC-HS.pdf As of port merge (and Florian's patch to fix static TLS), glibc testsuite (cross-test setup) has following failures: FAIL: elf/tst-audit14 FAIL: elf/tst-audit15 FAIL: elf/tst-audit16 FAIL: elf/tst-ldconfig-ld_so_conf-update FAIL: elf/tst-libc_dlvsym FAIL: elf/tst-libc_dlvsym-static FAIL: iconv/test-iconvconfig # Needs gconv installed FAIL: io/ftwtest # Requires execution by non-root FAIL: io/tst-lockf FAIL: libio/tst-wfile-sync FAIL: locale/tst-localedef-path-norm FAIL: nptl/test-cond-printers # needs Python3 and target GDB on target FAIL: nptl/test-condattr-printers # ditto FAIL: nptl/test-mutex-printers # ditto FAIL: nptl/test-mutexattr-printers # ditto FAIL: nptl/test-rwlock-printers # ditto FAIL: nptl/test-rwlockattr-printers # ditto FAIL: nptl/tst-umask1 # passes if run natively on target (NFS ACLv3 support needed) FAIL: nss/bug-erange FAIL: nss/tst-nss-files-hosts-getent FAIL: nss/tst-nss-files-hosts-multi FAIL: posix/bug-ga2 FAIL: posix/globtest # require same user on target and host FAIL: posix/tst-getaddrinfo5 FAIL: stdio-common/tst-vfprintf-width-prec FAIL: stdio-common/tst-vfprintf-width-prec-alloc FAIL: stdio-common/tst-vfprintf-width-prec-mem FAIL: string/tst-strerror FAIL: string/tst-strsignal FAIL: sunrpc/bug20790 # missing cpp on target FAIL: timezone/tst-tzset Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Add NEWS entry for Update to Unicode 13.0.0 [BZ #25819]Mike FABIAN2020-07-101-2/+2
| | | | | | | | | Unicode 13.0.0 Support: Character encoding, character type info, and transliteration tables are all updated to Unicode 13.0.0, using the generator scripts contributed by Mike FABIAN (Red Hat). Total added characters in newly generated CHARMAP: 5930 Total added characters in newly generated WIDTH: 5536
* Remove --enable-obsolete-nsl configure flagPetr Vorel2020-07-081-5/+15
| | | | | | | | | | | | | | | | | | | this means that *always* libnsl is only built as shared library for backward compatibility and the NSS modules libnss_nis and libnss_nisplus are not built at all, libnsl's headers aren't installed. This compatibility is kept only for architectures and ABIs that have been added in or before version 2.28. Replacement implementations based on TIRPC, which additionally support IPv6, are available from <https://github.com/thkukuk/>. This change does not affect libnss_compat which does not depended on libnsl since 2.27 and thus can be used without NIS. libnsl code depends on Sun RPC, e.g. on --enable-obsolete-rpc (installed libnsl headers use installed Sun RPC headers), which will be removed in the following commit.
* aarch64: add NEWS entry about branch protection supportSzabolcs Nagy2020-07-081-0/+11
| | | | | | This is a new security feature that relies on architecture extensions and needs glibc to be built with a gcc configured with branch protection.
* nss: Remove cryptographic key support from nss_files, nss_nis, nss_nisplusFlorian Weimer2020-07-071-0/+6
| | | | | | | | The interface has hard-coded buffer sizes and is therefore tied to DES. It also does not match current practice where different services on the same host use different key material. This change simplifies removal of the sunrpc code.
* string: Add strerrorname_np and strerrordesc_npAdhemerval Zanella2020-07-071-0/+10
| | | | | | | | | | | | | | | | | The strerrorname_np returns error number name (e.g. "EINVAL" for EINVAL) while strerrordesc_np returns string describing error number (e.g "Invalid argument" for EINVAL). Different than strerror, strerrordesc_np does not attempt to translate the return description, both functions return NULL for an invalid error number. They should be used instead of sys_errlist and sys_nerr, both are thread and async-signal safe. These functions are GNU extensions. Checked on x86-64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, and s390x-linux-gnu. Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>