about summary refs log tree commit diff
path: root/NEWS
Commit message (Collapse)AuthorAgeFilesLines
* Open master branch for glibc 2.40 development glibc-2.39.9000Andreas K. Hüttel2024-01-311-0/+27
| | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* NEWS: insert advisories and fixed bugs for 2.39Andreas K. Hüttel2024-01-301-4/+133
| | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* Fix typoAndreas K. Hüttel2024-01-301-1/+1
| | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* manual, NEWS: Document malloc side effect of dynamic TLS changesFlorian Weimer2024-01-241-0/+6
| | | | | | | | The increased malloc subsystem usage is a side effect of commit d2123d68275acc0f061e73d5f86ca504e0d5a344 ("elf: Fix slow tls access after dlopen [BZ #19924]"). Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
* NEWS: Update temporary files ignored by ldconfigFlorian Weimer2024-01-241-2/+2
| | | | | | | | | | Fixes commit 2aa0974d2573441bffd596b07bff8698b1f2f18c ("elf: ldconfig should skip temporary files created by package managers") and commit cfb5a97a93ea656e3b2263e42142a4032986d9ba ("ldconfig: Fixes for skipping temporary files."). Reported-by: Guillem Jover <guillem@debian.org> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* NEWS: Mention PLT rewrite on x86-64H.J. Lu2024-01-161-0/+4
| | | | Mention PLT rewrite on x86-64 for glibc 2.39.
* aarch64: Add NEWS entry about libmvec for 2.39Szabolcs Nagy2024-01-151-0/+7
| | | | | | Auto-vectorizing scalar calls is now supported. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* i386: Fail if configured with --enable-cetAdhemerval Zanella2024-01-091-2/+2
| | | | | | Since it is only supported for x86_64. Checked on i686-linux-gnu.
* Remove ia64-linux-gnuAdhemerval Zanella2024-01-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux 6.7 removed ia64 from the official tree [1], following the general principle that a glibc port needs upstream support for the architecture in all the components it depends on (binutils, GCC, and the Linux kernel). Apart from the removal of sysdeps/ia64 and sysdeps/unix/sysv/linux/ia64, there are updates to various comments referencing ia64 for which removal of those references seemed appropriate. The configuration is removed from README and build-many-glibcs.py. The CONTRIBUTED-BY, elf/elf.h, manual/contrib.texi (the porting mention), *.po files, config.guess, and longlong.h are not changed. For Linux it allows cleanup some clone2 support on multiple files. The following bug can be closed as WONTFIX: BZ 22634 [2], BZ 14250 [3], BZ 21634 [4], BZ 10163 [5], BZ 16401 [6], and BZ 11585 [7]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43ff221426d33db909f7159fdf620c3b052e2d1c [2] https://sourceware.org/bugzilla/show_bug.cgi?id=22634 [3] https://sourceware.org/bugzilla/show_bug.cgi?id=14250 [4] https://sourceware.org/bugzilla/show_bug.cgi?id=21634 [5] https://sourceware.org/bugzilla/show_bug.cgi?id=10163 [6] https://sourceware.org/bugzilla/show_bug.cgi?id=16401 [7] https://sourceware.org/bugzilla/show_bug.cgi?id=11585 Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* i386: Ignore --enable-cetH.J. Lu2024-01-041-0/+3
| | | | | | | | | | | | | | Since shadow stack is only supported for x86-64, ignore --enable-cet for i386. Always setting $(enable-cet) for i386 to "no" to support ifneq ($(enable-cet),no) in x86 Makefiles. We can't use ifeq ($(enable-cet),yes) since $(enable-cet) can be "yes", "no" or "permissive". Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Implement C23 <stdbit.h>Joseph Myers2024-01-031-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C23 adds a header <stdbit.h> with various functions and type-generic macros for bit-manipulation of unsigned integers (plus macro defines related to endianness). Implement this header for glibc. The functions have both inline definitions in the header (referenced by macros defined in the header) and copies with external linkage in the library (which are implemented in terms of those macros to avoid duplication). They are documented in the glibc manual. Tests, as well as verifying results for various inputs (of both the macros and the out-of-line functions), verify the types of those results (which showed up a bug in an earlier version with the type-generic macro stdc_has_single_bit wrongly returning a promoted type), that the macros can be used at top level in a source file (so don't use ({})), that they evaluate their arguments exactly once, and that the macros for the type-specific functions have the expected implicit conversions to the relevant argument type. Jakub previously referred to -Wconversion warnings in type-generic macros, so I've included a test with -Wconversion (but the only warnings I saw and fixed from that test were actually in inline functions in the <stdbit.h> header - not anything coming from use of the type-generic macros themselves). This implementation of the type-generic macros does not handle unsigned __int128, or unsigned _BitInt types with a width other than that of a standard integer type (and C23 doesn't require the header to handle such types either). Support for those types, using the new type-generic built-in functions Jakub's added for GCC 14, can reasonably be added in a followup (along of course with associated tests). This implementation doesn't do anything special to handle C++, or have any tests of functionality in C++ beyond the existing tests that all headers can be compiled in C++ code; it's not clear exactly what form this header should take in C++, but probably not one using macros. DIS ballot comment AT-107 asks for the word "count" to be added to the names of the stdc_leading_zeros, stdc_leading_ones, stdc_trailing_zeros and stdc_trailing_ones functions and macros. I don't think it's likely to be accepted (accepting any technical comments would mean having an FDIS ballot), but if it is accepted at the WG14 meeting (22-26 January in Strasbourg, starting with DIS ballot comment handling) then there would still be time to update glibc for the renaming before the 2.39 release. The new functions and header are placed in the stdlib/ directory in glibc, rather than creating a new toplevel stdbit/ or putting them in string/ alongside ffs. Tested for x86_64 and x86.
* Update copyright dates with scripts/update-copyrightsPaul Eggert2024-01-011-1/+1
|
* Move CVE information into advisories directorySiddhesh Poyarekar2023-12-071-19/+5
| | | | | | | | | | | | | | | | | | | One of the requirements to becoming a CVE Numbering Authority (CNA) is to publish advisories. Do this by maintaining a file for each CVE fixed in the advisories directory in the source tree. Links to the advisories can then be shared as: https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=advisories/GLIBC-SA-YYYY-NNNN The file format at the moment is rudimentary and derives from the git commit format, i.e. a subject line and a potentially multi-paragraph description and then tags to describe some meta information. This is a loose format at the moment and could change as we evolve this. Also add a script process-fixed-cves.sh that processes these advisories and generates a list to add to NEWS at release time. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* posix: Revert the removal of the crypt prototype from <unistd.h>Florian Weimer2023-11-221-1/+4
| | | | | | Many applications still rely on this prototype. Rebuilds without this prototype result in an implicit function declaration, which can introduce security vulnerabilities due to 32-bit pointer truncation.
* elf: Add glibc.mem.decorate_maps tunableAdhemerval Zanella2023-11-071-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PR_SET_VMA_ANON_NAME support is only enabled through a configurable kernel switch, mainly because assigning a name to a anonymous virtual memory area might prevent that area from being merged with adjacent virtual memory areas. For instance, with the following code: void *p1 = mmap (NULL, 1024 * 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); void *p2 = mmap (p1 + (1024 * 4096), 1024 * 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); The kernel will potentially merge both mappings resulting in only one segment of size 0x800000. If the segment is names with PR_SET_VMA_ANON_NAME with different names, it results in two mappings. Although this will unlikely be an issue for pthread stacks and malloc arenas (since for pthread stacks the guard page will result in a PROT_NONE segment, similar to the alignment requirement for the arena block), it still might prevent the mmap memory allocated for detail malloc. There is also another potential scalability issue, where the prctl requires to take the mmap global lock which is still not fully fixed in Linux [1] (for pthread stacks and arenas, it is mitigated by the stack cached and the arena reuse). So this patch disables anonymous mapping annotations as default and add a new tunable, glibc.mem.decorate_maps, can be used to enable it. [1] https://lwn.net/Articles/906852/ Checked on x86_64-linux-gnu and aarch64-linux-gnu. Reviewed-by: DJ Delorie <dj@redhat.com>
* crypt: Remove libcrypt supportAdhemerval Zanella2023-10-301-0/+16
| | | | | | | | | | | | | | | | | | All the crypt related functions, cryptographic algorithms, and make requirements are removed, with only the exception of md5 implementation which is moved to locale folder since it is required by localedef for integrity protection (libc's locale-reading code does not check these, but localedef does generate them). Besides thec code itself, both internal documentation and the manual is also adjusted. This allows to remove both --enable-crypt and --enable-nss-crypt configure options. Checked with a build for all affected ABIs. Co-authored-by: Zack Weinberg <zack@owlfolio.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* elf: ldconfig should skip temporary files created by package managersFlorian Weimer2023-10-201-1/+3
| | | | | | | This avoids crashes due to partially written files, after a package update is interrupted. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* tunables: Terminate if end of input is reached (CVE-2023-4911)Siddhesh Poyarekar2023-10-021-0/+5
| | | | | | | | | | | | | | | | | The string parsing routine may end up writing beyond bounds of tunestr if the input tunable string is malformed, of the form name=name=val. This gets processed twice, first as name=name=val and next as name=val, resulting in tunestr being name=name=val:name=val, thus overflowing tunestr. Terminate the parsing loop at the first instance itself so that tunestr does not overflow. This also fixes up tst-env-setuid-tunables to actually handle failures correct and add new tests to validate the fix for this CVE. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* C2x scanf %wN, %wfN supportJoseph Myers2023-09-281-0/+7
| | | | | | | | | ISO C2x defines scanf length modifiers wN (for intN_t / int_leastN_t / uintN_t / uint_leastN_t) and wfN (for int_fastN_t / uint_fastN_t). Add support for those length modifiers, similar to the printf support previously added. Tested for x86_64 and x86.
* Document CVE-2023-4806 and CVE-2023-5156 in NEWSSiddhesh Poyarekar2023-09-261-0/+9
| | | | | | These are tracked in BZ #30884 and BZ #30843. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* CVE-2023-4527: Stack read overflow with large TCP responses in no-aaaa modeFlorian Weimer2023-09-131-1/+5
| | | | | | | | | | | Without passing alt_dns_packet_buffer, __res_context_search can only store 2048 bytes (what fits into dns_packet_buffer). However, the function returns the total packet size, and the subsequent DNS parsing code in _nss_dns_gethostbyname4_r reads beyond the end of the stack-allocated buffer. Fixes commit f282cdbe7f436c75864e5640a4 ("resolv: Implement no-aaaa stub resolver option") and bug 30842.
* linux: Add pidfd_getpidAdhemerval Zanella Netto2023-09-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | This interface allows to obtain the associated process ID from the process file descriptor. It is done by parsing the procps fdinfo information. Its prototype is: pid_t pidfd_getpid (int fd) It returns the associated pid or -1 in case of an error and sets the errno accordingly. The possible errno values are those from open, read, and close (used on procps parsing), along with: - EBADF if the FD is negative, does not have a PID associated, or if the fdinfo fields contain a value larger than pid_t. - EREMOTE if the PID is in a separate namespace. - ESRCH if the process is already terminated. Checked on x86_64-linux-gnu on Linux 4.15 (no CLONE_PIDFD or waitid support), Linux 5.4 (full support), and Linux 6.2. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* posix: Add pidfd_spawn and pidfd_spawnp (BZ 30349)Adhemerval Zanella Netto2023-09-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Returning a pidfd allows a process to keep a race-free handle for a child process, otherwise, the caller will need to either use pidfd_open (which still might be subject to TOCTOU) or keep the old racy interface base on pid_t. To correct use pifd_spawn, the kernel must support not only returning the pidfd with clone/clone3 but also waitid (P_PIDFD) (added on Linux 5.4). If kernel does not support the waitid, pidfd return ENOSYS. It avoids the need to racy workarounds, such as reading the procfs fdinfo to get the pid to use along with other wait interfaces. These interfaces are similar to the posix_spawn and posix_spawnp, with the only difference being it returns a process file descriptor (int) instead of a process ID (pid_t). Their prototypes are: int pidfd_spawn (int *restrict pidfd, const char *restrict file, const posix_spawn_file_actions_t *restrict facts, const posix_spawnattr_t *restrict attrp, char *const argv[restrict], char *const envp[restrict]) int pidfd_spawnp (int *restrict pidfd, const char *restrict path, const posix_spawn_file_actions_t *restrict facts, const posix_spawnattr_t *restrict attrp, char *const argv[restrict_arr], char *const envp[restrict_arr]); A new symbol is used instead of a posix_spawn extension to avoid possible issues with language bindings that might track the return argument lifetime. Although on Linux pid_t and int are interchangeable, POSIX only states that pid_t should be a signed integer. Both symbols reuse the posix_spawn posix_spawn_file_actions_t and posix_spawnattr_t, to void rehash posix_spawn API or add a new one. It also means that both interfaces support the same attribute and file actions, and a new flag or file action on posix_spawn is also added automatically for pidfd_spawn. Also, using posix_spawn plumbing allows the reusing of most of the current testing with some changes: - waitid is used instead of waitpid since it is a more generic interface. - tst-posix_spawn-setsid.c is adapted to take into consideration that the caller can check for session id directly. The test now spawns itself and writes the session id as a file instead. - tst-spawn3.c need to know where pidfd_spawn is used so it keeps an extra file description unused. Checked on x86_64-linux-gnu on Linux 4.15 (no CLONE_PIDFD or waitid support), Linux 5.4 (full support), and Linux 6.2. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* linux: Add posix_spawnattr_{get, set}cgroup_np (BZ 26371)Adhemerval Zanella Netto2023-09-051-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | These functions allow to posix_spawn and posix_spawnp to use CLONE_INTO_CGROUP with clone3, allowing the child process to be created in a different cgroup version 2. These are GNU extensions that are available only for Linux, and also only for the architectures that implement clone3 wrapper (HAVE_CLONE3_WRAPPER). To create a process on a different cgroupv2, one can use the: posix_spawnattr_t attr; posix_spawnattr_init (&attr); posix_spawnattr_setflags (&attr, POSIX_SPAWN_SETCGROUP); posix_spawnattr_setcgroup_np (&attr, cgroup); posix_spawn (...) Similar to other posix_spawn flags, POSIX_SPAWN_SETCGROUP control whether the cgroup file descriptor will be used or not with clone3. There is no fallback if either clone3 does not support the flag or if the architecture does not provide the clone3 wrapper, in this case posix_spawn returns EOPNOTSUPP. Checked on x86_64-linux-gnu. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* LoongArch: Add minuimum binutils required versiondengjianbo2023-08-141-1/+2
| | | | | | | LoongArch glibc can add some LASX/LSX vector instructions codes, change the required minimum binutils version to 2.41 which could support vector instructions. HAVE_LOONGARCH_VEC_ASM is removed accordingly.
* linux: statvfs: allocate spare for f_typeнаб2023-08-081-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | This is the only missing part in struct statvfs. The LSB calls [f]statfs() deprecated, and its weird types are definitely off-putting. However, its use is required to get f_type. Instead, allocate one of the six spares to f_type, copied directly from struct statfs. This then becomes a small glibc extension to the standard interface on Linux and the Hurd, instead of two different interfaces, one of which is quite odd due to being an ABI type, and there no longer is any reason to use statfs(). The underlying kernel type is a mess, but all architectures agree on u32 (or more) for the ABI, and all filesystem magicks are 32-bit integers. We don't lose any generality by using u32, and by doing so we both make the API consistent with the Hurd, and allow C++ switch(f_type) { case RAMFS_MAGIC: ...; } Also fix tst-statvfs so that it actually fails; as it stood, all it did was return 0 always. Test statfs()' and statvfs()' f_types are the same. Link: https://lore.kernel.org/linux-man/f54kudgblgk643u32tb6at4cd3kkzha6hslahv24szs4raroaz@ogivjbfdaqtb/t/#u Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Open master branch for glibc 2.39 development glibc-2.38.9000Andreas K. Hüttel2023-07-311-0/+23
| | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* NEWS: Fix typos glibc-2.38Andreas K. Hüttel2023-07-311-2/+3
| | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* NEWS: minor wording fixesAndreas K. Hüttel2023-07-301-2/+2
| | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* NEWS: Insert autogenerated list of fixed bugsAndreas K. Hüttel2023-07-251-2/+41
| | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* NEWS: Mention AArch64 libmvec under build requirements againAndreas K. Hüttel2023-07-251-1/+1
| | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* NEWS: Minor editorial changesAndreas K. Hüttel2023-07-251-9/+9
| | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* configure: Disable building libcrypt by defaultSiddhesh Poyarekar2023-07-201-0/+5
| | | | | | | | | | | | We mentioned eventual dropping of libcrypt in the 2.28 NEWS. Actually put that plan in motion by first disabling building libcrypt by default. note in NEWS that the library will be dropped completely in a future release. Also add a couple of builds into build-many-glibcs.py. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* Allow glibc to be built with _FORTIFY_SOURCEFrédéric Bérat2023-07-051-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add --enable-fortify-source option. It is now possible to enable fortification through a configure option. The level may be given as parameter, if none is provided, the configure script will determine what is the highest level possible that can be set considering GCC built-ins availability and set it. If level is explicitly set to 3, configure checks if the compiler supports the built-in function necessary for it or raise an error if it isn't. If the configure option isn't explicitly enabled, it _FORTIFY_SOURCE is forcibly undefined (and therefore disabled). The result of the configure checks are new variables, ${fortify_source} and ${no_fortify_source} that can be used to appropriately populate CFLAGS. A dedicated patch will follow to make use of this variable in Makefiles when necessary. Updated NEWS and INSTALL. Adding dedicated x86_64 variant that enables the configuration. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* C2x scanf %b supportJoseph Myers2023-06-191-2/+5
| | | | | | | | | | | | ISO C2x defines scanf %b for input of binary integers (with an optional 0b or 0B prefix). Implement such support, along with the corresponding SCNb* macros in <inttypes.h>. Unlike the support for binary integers with 0b or 0B prefix with scanf %i, this is supported in all versions of scanf (independent of the standards mode used for compilation), because there are no backwards compatibility concerns (%b wasn't previously a supported format) the way there were for %i. Tested for x86_64 and x86.
* C2x printf %wN, %wfN support (bug 24466)Joseph Myers2023-06-191-0/+7
| | | | | | | | | | | | | | | | | | ISO C2x defines printf length modifiers wN (for intN_t / int_leastN_t / uintN_t / uint_leastN_t) and wfN (for int_fastN_t / uint_fastN_t). Add support for those length modifiers (such a feature was previously requested in bug 24466). scanf support is to be added separately. GCC 13 has format checking support for these modifiers. When used with the support for registering format specifiers, these modifiers are translated to existing flags in struct printf_info, rather than trying to add some way of distinguishing them without breaking the printf_info ABI. C2x requires an error to be returned for unsupported values of N; this is implemented for printf-family functions, but the parse_printf_format interface doesn't support error returns, so such an error gets discarded by that function. Tested for x86_64 and x86.
* Implement strlcpy and strlcat [BZ #178]Florian Weimer2023-06-141-0/+3
| | | | | | | | | | | These functions are about to be added to POSIX, under Austin Group issue 986. The fortified strlcat implementation does not raise SIGABRT if the destination buffer does not contain a null terminator, it just inherits the non-failing regular strlcat behavior. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Fix all the remaining misspellings -- BZ 25337Paul Pluzhnikov2023-06-021-16/+16
|
* Enable libmvec support for AArch64Joe Ramsay2023-05-031-0/+6
| | | | | | | | | | | | | | | | | | | | | | | This patch enables libmvec on AArch64. The proposed change is mainly implementing build infrastructure to add the new routines to ABI, tests and benchmarks. I have demonstrated how this all fits together by adding implementations for vector cos, in both single and double precision, targeting both Advanced SIMD and SVE. The implementations of the routines themselves are just loops over the scalar routine from libm for now, as we are more concerned with getting the plumbing right at this point. We plan to contribute vector routines from the Arm Optimized Routines repo that are compliant with requirements described in the libmvec wiki. Building libmvec requires minimum GCC 10 for SVE ACLE. To avoid raising the minimum GCC by such a big jump, we allow users to disable libmvec if their compiler is too old. Note that at this point users have to manually call the vector math functions. This seems to be acceptable to some downstream users. Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
* hurd: Enable x86_64 build scriptSamuel Thibault2023-05-021-0/+5
| | | | This now passes crossbuilds.
* Created tunable to force small pages on stack allocation.Cupertino Miranda2023-04-201-0/+3
| | | | | | | | | | Created tunable glibc.pthread.stack_hugetlb to control when hugepages can be used for stack allocation. In case THP are enabled and glibc.pthread.stack_hugetlb is set to 0, glibc will madvise the kernel not to use allow hugepages for stack allocations. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Remove --enable-tunables configure optionAdhemerval Zanella Netto2023-03-291-0/+3
| | | | | | | | | | | | And make always supported. The configure option was added on glibc 2.25 and some features require it (such as hwcap mask, huge pages support, and lock elisition tuning). It also simplifies the build permutations. Changes from v1: * Remove glibc.rtld.dynamic_sort changes, it is orthogonal and needs more discussion. * Cleanup more code. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Remove --disable-experimental-malloc optionAdhemerval Zanella2023-03-291-0/+4
| | | | | | | | | | | | | | | | | | | It is the default since 2.26 and it has bitrotten over the years, By using it multiple malloc tests fails: FAIL: malloc/tst-memalign-2 FAIL: malloc/tst-memalign-2-malloc-hugetlb1 FAIL: malloc/tst-memalign-2-malloc-hugetlb2 FAIL: malloc/tst-memalign-2-mcheck FAIL: malloc/tst-mxfast-malloc-hugetlb1 FAIL: malloc/tst-mxfast-malloc-hugetlb2 FAIL: malloc/tst-tcfree2 FAIL: malloc/tst-tcfree2-malloc-hugetlb1 FAIL: malloc/tst-tcfree2-malloc-hugetlb2 Checked on x86_64-linux-gnu. Reviewed-by: DJ Delorie <dj@redhat.com>
* Update printf %b/%B C2x supportJoseph Myers2023-03-141-0/+2
| | | | | | | | | | | | | | | | WG14 recently accepted two additions to the printf/scanf %b/%B support: there are now PRIb* and SCNb* macros in <inttypes.h>, and printf %B is now an optional feature defined in normative text, instead of recommended practice, with corresponding PRIB* macros that can also be used to test whether that optional feature is supported. See N3072 items 14 and 15 for details (those changes were accepted, some other changes in that paper weren't). Add the corresponding PRI* macros to glibc and update one place in the manual referring to %B as recommended. (SCNb* should naturally be added at the same time as the corresponding scanf %b support.) Tested for x86_64 and x86.
* C2x scanf binary constant handlingJoseph Myers2023-03-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | C2x adds binary integer constants starting with 0b or 0B, and supports those constants for the %i scanf format (in addition to the %b format, which isn't yet implemented for scanf in glibc). Implement that scanf support for glibc. As with the strtol support, this is incompatible with previous C standard versions, in that such an input string starting with 0b or 0B was previously required to be parsed as 0 (with the rest of the input potentially matching subsequent parts of the scanf format string). Thus this patch adds 12 new __isoc23_* functions per long double format (12, 24 or 36 depending on how many long double formats the glibc configuration supports), with appropriate header redirection support (generally very closely following that for the __isoc99_* scanf functions - note that __GLIBC_USE (DEPRECATED_SCANF) takes precedence over __GLIBC_USE (C2X_STRTOL), so the case of GNU extensions to C89 continues to get old-style GNU %a and does not get this new feature). The function names would remain as __isoc23_* even if C2x ends up published in 2024 rather than 2023. When scanf %b support is added, I think it will be appropriate for all versions of scanf to follow C2x rules for inputs to the %b format (given that there are no compatibility concerns for a new format). Tested for x86_64 (full glibc testsuite). The first version was also tested for powerpc (32-bit) and powerpc64le (stdio-common/ and wcsmbs/ tests), and with build-many-glibcs.py.
* hppa: Drop old parisc-specific MADV_* constantsJohn David Anglin2023-02-251-1/+6
| | | | | | | | | | | | | | | | | | | The Linux kernel upstream commit 71bdea6f798b ("parisc: Align parisc MADV_XXX constants with all other architectures") dropped the parisc-specific MADV_* values in favour of the same constants as other architectures. In the same commit a wrapper was added which translates the old values to the standard MADV_* values to avoid breakage of existing programs. This upstream patch has been downported to all stable kernel trees as well. This patch now drops the parisc specific constants from glibc to allow newly compliled programs to use the standard MADV_* constants. v2: Added NEWS section, based on feedback from Florian Weimer Signed-off-by: Helge Deller <deller@gmx.de>
* C2x strtol binary constant handlingJoseph Myers2023-02-161-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C2x adds binary integer constants starting with 0b or 0B, and supports those constants in strtol-family functions when the base passed is 0 or 2. Implement that strtol support for glibc. As discussed at <https://sourceware.org/pipermail/libc-alpha/2020-December/120414.html>, this is incompatible with previous C standard versions, in that such an input string starting with 0b or 0B was previously required to be parsed as 0 (with the rest of the string unprocessed). Thus, as proposed there, this patch adds 20 new __isoc23_* functions with appropriate header redirection support. This patch does *not* do anything about scanf %i (which will need 12 new functions per long double variant, so 12, 24 or 36 depending on the glibc configuration), instead leaving that for a future patch. The function names would remain as __isoc23_* even if C2x ends up published in 2024 rather than 2023. Making this change leads to the question of what should happen to internal uses of these functions in glibc and its tests. The header redirection (which applies for _GNU_SOURCE or any other feature test macros enabling C2x features) has the effect of redirecting internal uses but without those uses then ending up at a hidden alias (see the comment in include/stdio.h about interaction with libc_hidden_proto). It seems desirable for the default for internal uses to be the same versions used by normal code using _GNU_SOURCE, so rather than doing anything to disable that redirection, similar macro definitions to those in include/stdio.h are added to the include/ headers for the new functions. Given that the default for uses in glibc is for the redirections to apply, the next question is whether the C2x semantics are correct for all those uses. Uses with the base fixed to 10, 16 or any other value other than 0 or 2 can be ignored. I think this leaves the following internal uses to consider (an important consideration for review of this patch will be both whether this list is complete and whether my conclusions on all entries in it are correct): benchtests/bench-malloc-simple.c benchtests/bench-string.h elf/sotruss-lib.c math/libm-test-support.c nptl/perf.c nscd/nscd_conf.c nss/nss_files/files-parse.c posix/tst-fnmatch.c posix/wordexp.c resolv/inet_addr.c rt/tst-mqueue7.c soft-fp/testit.c stdlib/fmtmsg.c support/support_test_main.c support/test-container.c sysdeps/pthread/tst-mutex10.c I think all of these places are OK with the new semantics, except for resolv/inet_addr.c, where the POSIX semantics of inet_addr do not allow for binary constants; thus, I changed that file (to use __strtoul_internal, whose semantics are unchanged) and added a test for this case. In the case of posix/wordexp.c I think accepting binary constants is OK since POSIX explicitly allows additional forms of shell arithmetic expressions, and in stdlib/fmtmsg.c SEV_LEVEL is not in POSIX so again I think accepting binary constants is OK. Functions such as __strtol_internal, which are only exported for compatibility with old binaries from when those were used in inline functions in headers, have unchanged semantics; the __*_l_internal versions (purely internal to libc and not exported) have a new argument to specify whether to accept binary constants. As well as for the standard functions, the header redirection also applies to the *_l versions (GNU extensions), and to legacy functions such as strtoq, to avoid confusing inconsistency (the *q functions redirect to __isoc23_*ll rather than needing their own __isoc23_* entry points). For the functions that are only declared with _GNU_SOURCE, this means the old versions are no longer available for normal user programs at all. An internal __GLIBC_USE_C2X_STRTOL macro is used to control the redirections in the headers, and cases in glibc that wish to avoid the redirections - the function implementations themselves and the tests of the old versions of the GNU functions - then undefine and redefine that macro to allow the old versions to be accessed. (There would of course be greater complexity should we wish to make any of the old versions into compat symbols / avoid them being defined at all for new glibc ABIs.) strtol_l.c has some similarity to strtol.c in gnulib, but has already diverged some way (and isn't listed at all at https://sourceware.org/glibc/wiki/SharedSourceFiles unlike strtoll.c and strtoul.c); I haven't made any attempts at gnulib compatibility in the changes to that file. I note incidentally that inttypes.h and wchar.h are missing the __nonnull present on declarations of this family of functions in stdlib.h; I didn't make any changes in that regard for the new declarations added.
* NEWS: Document CVE-2023-25139.Carlos O'Donell2023-02-071-1/+6
| | | | Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Open master branch for glibc 2.38 development glibc-2.37.9000Carlos O'Donell2023-01-311-0/+23
|
* Update NEWS file with bug fixes.Carlos O'Donell2023-01-311-6/+75
|
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-06-02 21:00:10 +0000