about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
...
* x86-64: Fix the dtv field load for x32 [BZ #31184]H.J. Lu2023-12-232-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On x32, I got FAIL: elf/tst-tlsgap $ gdb elf/tst-tlsgap ... open tst-tlsgap-mod1.so Thread 2 "tst-tlsgap" received signal SIGSEGV, Segmentation fault. [Switching to LWP 2268754] _dl_tlsdesc_dynamic () at ../sysdeps/x86_64/dl-tlsdesc.S:108 108 movq (%rsi), %rax (gdb) p/x $rsi $4 = 0xf7dbf9005655fb18 (gdb) This is caused by _dl_tlsdesc_dynamic: _CET_ENDBR /* Preserve call-clobbered registers that we modify. We need two scratch regs anyway. */ movq %rsi, -16(%rsp) movq %fs:DTV_OFFSET, %rsi Since the dtv field in TCB is a pointer, %fs:DTV_OFFSET is a 32-bit location, not 64-bit. Load the dtv field to RSI_LP instead of rsi. This fixes BZ #31184. (cherry picked from commit 3502440397bbb840e2f7223734aa5cc2cc0e29b6)
* elf: Fix TLS modid reuse generation assignment (BZ 29039)Hector Martin2023-12-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _dl_assign_tls_modid() assigns a slotinfo entry for a new module, but does *not* do anything to the generation counter. The first time this happens, the generation is zero and map_generation() returns the current generation to be used during relocation processing. However, if a slotinfo entry is later reused, it will already have a generation assigned. If this generation has fallen behind the current global max generation, then this causes an obsolete generation to be assigned during relocation processing, as map_generation() returns this generation if nonzero. _dl_add_to_slotinfo() eventually resets the generation, but by then it is too late. This causes DTV updates to be skipped, leading to NULL or broken TLS slot pointers and segfaults. Fix this by resetting the generation to zero in _dl_assign_tls_modid(), so it behaves the same as the first time a slot is assigned. _dl_add_to_slotinfo() will still assign the correct static generation later during module load, but relocation processing will no longer use an obsolete generation. Note that slotinfo entry (aka modid) reuse typically happens after a dlclose and only TLS access via dynamic tlsdesc is affected. Because tlsdesc is optimized to use the optional part of static TLS, dynamic tlsdesc can be avoided by increasing the glibc.rtld.optional_static_tls tunable to a large enough value, or by LD_PRELOAD-ing the affected modules. Fixes bug 29039. Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com> (cherry picked from commit 3921c5b40f293c57cb326f58713c924b0662ef59)
* elf: Fix wrong break removal from 8ee878592cAdhemerval Zanella2023-12-071-0/+1
| | | | | Reported-by: Alexander Monakov <amonakov@ispras.ru> (cherry picked from commit 546a1ba664626603660b595662249d524e429013)
* Revert "elf: Move l_init_called_next to old place of l_text_end in link map"Florian Weimer2023-10-191-4/+4
| | | | | | This reverts commit 1a7cbe52c8955beae477cf9c6d88f4bc04f626c1. Reason for revert: Preserve internal ABI.
* Revert "elf: Always call destructors in reverse constructor order (bug 30785)"Florian Weimer2023-10-187-176/+173
| | | | | | This reverts commit a7e34a667585f675143563569688756f4f4a6e47. Reason for revert: Incompatibility with existing applications.
* Revert "elf: Remove unused l_text_end field from struct link_map"Florian Weimer2023-10-185-3/+18
| | | | | | This reverts commit bdb594afa515d0150f8f092c45e04942d20ecb61. Reason for revert: Preserve ABI after revert of commit a7e34a66758.
* tunables: Terminate if end of input is reached (CVE-2023-4911)Siddhesh Poyarekar2023-10-023-15/+44
| | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 1056e5b4c3f2d90ed2b4a55f96add28da2f4c8fa)
* i686: Regenerate ulpsAndreas K. Hüttel2023-09-291-1/+1
| | | | | | | Linux dilfridge-amd64-stable 6.1.41-gentoo-dist #1 SMP PREEMPT_DYNAMIC Tue Jul 25 09:26:34 -00 2023 x86_64 AMD Ryzen 7 3700X 8-Core Processor AuthenticAMD GNU/Linux 32bit build on x86-64 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* 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> (cherry picked from commit fd134feba35fa839018965733b34d28a09a075dd)
* Fix leak in getaddrinfo introduced by the fix for CVE-2023-4806 [BZ #30843]Romain Geissler2023-09-263-3/+24
| | | | | | | | | | | | This patch fixes a very recently added leak in getaddrinfo. This was assigned CVE-2023-5156. Resolves: BZ #30884 Related: BZ #30842 Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit ec6b95c3303c700eb89eebeda2d7264cc184a796)
* x86: Fix for cache computation on AMD legacy cpus.Sajan Karumanchi2023-09-262-27/+200
| | | | | | | | | | | | Some legacy AMD CPUs and hypervisors have the _cpuid_ '0x8000_001D' set to Zero, thus resulting in zeroed-out computed cache values. This patch reintroduces the old way of cache computation as a fail-safe option to handle these exceptions. Fixed 'level4_cache_size' value through handle_amd(). Reviewed-by: Premachandra Mallappa <premachandra.mallappa@amd.com> Tested-by: Florian Weimer <fweimer@redhat.com> (cherry picked from commit dcad5c8578130dec7f35fd5b0885304b59f9f543)
* x86/dl-cacheinfo: remove unsused parameter from handle_amdAndreas Schwab2023-09-261-35/+29
| | | | | | Also replace an unreachable assert with __builtin_unreachable. (cherry picked from commit 856bab7717ef6d1033fd7cbf7cfb2ddefbfffb07)
* getaddrinfo: Fix use after free in getcanonname (CVE-2023-4806)Siddhesh Poyarekar2023-09-157-10/+152
| | | | | | | | | | | | | | | | | | | | | | | | When an NSS plugin only implements the _gethostbyname2_r and _getcanonname_r callbacks, getaddrinfo could use memory that was freed during tmpbuf resizing, through h_name in a previous query response. The backing store for res->at->name when doing a query with gethostbyname3_r or gethostbyname2_r is tmpbuf, which is reallocated in gethosts during the query. For AF_INET6 lookup with AI_ALL | AI_V4MAPPED, gethosts gets called twice, once for a v6 lookup and second for a v4 lookup. In this case, if the first call reallocates tmpbuf enough number of times, resulting in a malloc, th->h_name (that res->at->name refers to) ends up on a heap allocated storage in tmpbuf. Now if the second call to gethosts also causes the plugin callback to return NSS_STATUS_TRYAGAIN, tmpbuf will get freed, resulting in a UAF reference in res->at->name. This then gets dereferenced in the getcanonname_r plugin call, resulting in the use after free. Fix this by copying h_name over and freeing it at the end. This resolves BZ #30843, which is assigned CVE-2023-4806. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit 973fe93a5675c42798b2161c6f29c01b0e243994)
* CVE-2023-4527: Stack read overflow with large TCP responses in no-aaaa modeFlorian Weimer2023-09-134-1/+139
| | | | | | | | | | | | | 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. (cherry picked from commit bd77dd7e73e3530203be1c52c8a29d08270cb25d)
* elf: Move l_init_called_next to old place of l_text_end in link mapFlorian Weimer2023-09-111-4/+4
| | | | | This preserves all member offsets and the GLIBC_PRIVATE ABI for backporting.
* elf: Remove unused l_text_end field from struct link_mapFlorian Weimer2023-09-115-18/+3
| | | | | | | | | | | | | | It is a left-over from commit 52a01100ad011293197637e42b5be1a479a2 ("elf: Remove ad-hoc restrictions on dlopen callers [BZ #22787]"). When backporting commmit 6985865bc3ad5b23147ee73466583dd7fdf65892 ("elf: Always call destructors in reverse constructor order (bug 30785)"), we can move the l_init_called_next field to this place, so that the internal GLIBC_PRIVATE ABI does not change. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 53df2ce6885da3d0e89e87dca7b095622296014f)
* elf: Always call destructors in reverse constructor order (bug 30785)Florian Weimer2023-09-118-173/+180
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current implementation of dlclose (and process exit) re-sorts the link maps before calling ELF destructors. Destructor order is not the reverse of the constructor order as a result: The second sort takes relocation dependencies into account, and other differences can result from ambiguous inputs, such as cycles. (The force_first handling in _dl_sort_maps is not effective for dlclose.) After the changes in this commit, there is still a required difference due to dlopen/dlclose ordering by the application, but the previous discrepancies went beyond that. A new global (namespace-spanning) list of link maps, _dl_init_called_list, is updated right before ELF constructors are called from _dl_init. In dl_close_worker, the maps variable, an on-stack variable length array, is eliminated. (VLAs are problematic, and dlclose should not call malloc because it cannot readily deal with malloc failure.) Marking still-used objects uses the namespace list directly, with next and next_idx replacing the done_index variable. After marking, _dl_init_called_list is used to call the destructors of now-unused maps in reverse destructor order. These destructors can call dlopen. Previously, new objects do not have l_map_used set. This had to change: There is no copy of the link map list anymore, so processing would cover newly opened (and unmarked) mappings, unloading them. Now, _dl_init (indirectly) sets l_map_used, too. (dlclose is handled by the existing reentrancy guard.) After _dl_init_called_list traversal, two more loops follow. The processing order changes to the original link map order in the namespace. Previously, dependency order was used. The difference should not matter because relocation dependencies could already reorder link maps in the old code. The changes to _dl_fini remove the sorting step and replace it with a traversal of _dl_init_called_list. The l_direct_opencount decrement outside the loader lock is removed because it appears incorrect: the counter manipulation could race with other dynamic loader operations. tst-audit23 needs adjustments to the changes in LA_ACT_DELETE notifications. The new approach for checking la_activity should make it clearer that la_activty calls come in pairs around namespace updates. The dependency sorting test cases need updates because the destructor order is always the opposite order of constructor order, even with relocation dependencies or cycles present. There is a future cleanup opportunity to remove the now-constant force_first and for_fini arguments from the _dl_sort_maps function. Fixes commit 1df71d32fe5f5905ffd5d100e5e9ca8ad62 ("elf: Implement force_first handling in _dl_sort_maps_dfs (bug 28937)"). Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit 6985865bc3ad5b23147ee73466583dd7fdf65892)
* elf: Do not run constructors for proxy objectsFlorian Weimer2023-09-111-2/+6
| | | | | | | Otherwise, the ld.so constructor runs for each audit namespace and each dlmopen namespace. (cherry picked from commit f6c8204fd7fabf0cf4162eaf10ccf23258e4d10e)
* io: Fix record locking contants for powerpc64 with __USE_FILE_OFFSET64Aurelien Jarno2023-09-074-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 5f828ff824e3b7cd1 ("io: Fix F_GETLK, F_SETLK, and F_SETLKW for powerpc64") fixed an issue with the value of the lock constants on powerpc64 when not using __USE_FILE_OFFSET64, but it ended-up also changing the value when using __USE_FILE_OFFSET64 causing an API change. Fix that by also checking that define, restoring the pre 4d0fe291aed3a476a commit values: Default values: - F_GETLK: 5 - F_SETLK: 6 - F_SETLKW: 7 With -D_FILE_OFFSET_BITS=64: - F_GETLK: 12 - F_SETLK: 13 - F_SETLKW: 14 At the same time, it has been noticed that there was no test for io lock with __USE_FILE_OFFSET64, so just add one. Tested on x86_64-linux-gnu, i686-linux-gnu and powerpc64le-unknown-linux-gnu. Resolves: BZ #30804. Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> (cherry picked from commit 434bf72a94de68f0cc7fbf3c44bf38c1911b70cb)
* hurd: Make exception subcode a longSergey Bugaev2023-08-293-4/+5
| | | | | | | | | On EXC_BAD_ACCESS, exception subcode is used to pass the faulting memory address, so it needs to be (at least) pointer-sized. Thus, make it into a long. This matches the corresponding change in GNU Mach. Message-Id: <20230319151017.531737-5-bugaevc@gmail.com> (cherry picked from commit d8ee5d614bc485f6d1752dfa0d60524b20945a56)
* x86: Fix incorrect scope of setting `shared_per_thread` [BZ# 30745]Noah Goldstein2023-08-281-4/+3
| | | | | | | | | | | | | | | | The: ``` if (shared_per_thread > 0 && threads > 0) shared_per_thread /= threads; ``` Code was accidentally moved to inside the else scope. This doesn't match how it was previously (before af992e7abd). This patch fixes that by putting the division after the `else` block. (cherry picked from commit 084fb31bc2c5f95ae0b9e6df4d3cf0ff43471ede)
* x86: Use `3/4*sizeof(per-thread-L3)` as low bound for NT threshold.Noah Goldstein2023-08-281-1/+10
| | | | | | | | | | | On some machines we end up with incomplete cache information. This can make the new calculation of `sizeof(total-L3)/custom-divisor` end up lower than intended (and lower than the prior value). So reintroduce the old bound as a lower bound to avoid potentially regressing code where we don't have complete information to make the decision. Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit 8b9a0af8ca012217bf90d1dc0694f85b49ae09da)
* x86: Fix slight bug in `shared_per_thread` cache size calculation.Noah Goldstein2023-08-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | After: ``` commit af992e7abdc9049714da76cae1e5e18bc4838fb8 Author: Noah Goldstein <goldstein.w.n@gmail.com> Date: Wed Jun 7 13:18:01 2023 -0500 x86: Increase `non_temporal_threshold` to roughly `sizeof_L3 / 4` ``` Split `shared` (cumulative cache size) from `shared_per_thread` (cache size per socket), the `shared_per_thread` *can* be slightly off from the previous calculation. Previously we added `core` even if `threads_l2` was invalid, and only used `threads_l2` to divide `core` if it was present. The changed version only included `core` if `threads_l2` was valid. This change restores the old behavior if `threads_l2` is invalid by adding the entire value of `core`. Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit 47f747217811db35854ea06741be3685e8bbd44d)
* x86: Increase `non_temporal_threshold` to roughly `sizeof_L3 / 4`Noah Goldstein2023-08-281-28/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current `non_temporal_threshold` set to roughly '3/4 * sizeof_L3 / ncores_per_socket'. This patch updates that value to roughly 'sizeof_L3 / 4` The original value (specifically dividing the `ncores_per_socket`) was done to limit the amount of other threads' data a `memcpy`/`memset` could evict. Dividing by 'ncores_per_socket', however leads to exceedingly low non-temporal thresholds and leads to using non-temporal stores in cases where REP MOVSB is multiple times faster. Furthermore, non-temporal stores are written directly to main memory so using it at a size much smaller than L3 can place soon to be accessed data much further away than it otherwise could be. As well, modern machines are able to detect streaming patterns (especially if REP MOVSB is used) and provide LRU hints to the memory subsystem. This in affect caps the total amount of eviction at 1/cache_associativity, far below meaningfully thrashing the entire cache. As best I can tell, the benchmarks that lead this small threshold where done comparing non-temporal stores versus standard cacheable stores. A better comparison (linked below) is to be REP MOVSB which, on the measure systems, is nearly 2x faster than non-temporal stores at the low-end of the previous threshold, and within 10% for over 100MB copies (well past even the current threshold). In cases with a low number of threads competing for bandwidth, REP MOVSB is ~2x faster up to `sizeof_L3`. The divisor of `4` is a somewhat arbitrary value. From benchmarks it seems Skylake and Icelake both prefer a divisor of `2`, but older CPUs such as Broadwell prefer something closer to `8`. This patch is meant to be followed up by another one to make the divisor cpu-specific, but in the meantime (and for easier backporting), this patch settles on `4` as a middle-ground. Benchmarks comparing non-temporal stores, REP MOVSB, and cacheable stores where done using: https://github.com/goldsteinn/memcpy-nt-benchmarks Sheets results (also available in pdf on the github): https://docs.google.com/spreadsheets/d/e/2PACX-1vS183r0rW_jRX6tG_E90m9qVuFiMbRIJvi5VAE8yYOvEOIEEc3aSNuEsrFbuXw5c3nGboxMmrupZD7K/pubhtml Reviewed-by: DJ Delorie <dj@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit af992e7abdc9049714da76cae1e5e18bc4838fb8)
* sparc: Fix la_symbind for bind-now (BZ 23734)Adhemerval Zanella2023-07-129-14/+66
| | | | | | | | | | | | | | | | | | | | | | | The sparc ABI has multiple cases on how to handle JMP_SLOT relocations, (sparc_fixup_plt/sparc64_fixup_plt). For BINDNOW, _dl_audit_symbind will be responsible to setup the final relocation value; while for lazy binding _dl_fixup/_dl_profile_fixup will call the audit callback and tail cail elf_machine_fixup_plt (which will call sparc64_fixup_plt). This patch fixes by issuing the SPARC specific routine on bindnow and forwarding the audit value to elf_machine_fixup_plt for lazy resolution. It fixes the la_symbind for bind-now tests on sparc64 and sparcv9: elf/tst-audit24a elf/tst-audit24b elf/tst-audit24c elf/tst-audit24d Checked on sparc64-linux-gnu and sparcv9-linux-gnu. Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> (cherry picked from commit dddc88587a7f48cbb361d9929ec23d790164eef8)
* nptl: Fix tst-cancel30 on sparc64Adhemerval Zanella2023-07-101-3/+1
| | | | | | | | As indicated by sparc kernel-features.h, even though sparc64 defines __NR_pause, it is not supported (ENOSYS). Always use ppoll or the 64 bit time_t variant instead. (cherry picked from commit 370da8a121c3ba9eeb2f13da15fc0f21f4136b25)
* elf: _dl_find_object may return 1 during early startup (bug 30515)Florian Weimer2023-07-073-1/+13
| | | | | | | | | | | | | Success is reported with a 0 return value, and failure is -1. Enhance the kitchen sink test elf/tst-audit28 to cover _dl_find_object as well. Fixes commit 5d28a8962dcb ("elf: Add _dl_find_object function") and bug 30515. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 1bcfe0f732066ae5336b252295591ebe7e51c301)
* realloc: Limit chunk reuse to only growing requests [BZ #30579]Siddhesh Poyarekar2023-07-061-8/+15
| | | | | | | | | | | | | | | | | | | | | | The trim_threshold is too aggressive a heuristic to decide if chunk reuse is OK for reallocated memory; for repeated small, shrinking allocations it leads to internal fragmentation and for repeated larger allocations that fragmentation may blow up even worse due to the dynamic nature of the threshold. Limit reuse only when it is within the alignment padding, which is 2 * size_t for heap allocations and a page size for mmapped allocations. There's the added wrinkle of THP, but this fix ignores it for now, pessimizing that case in favor of keeping fragmentation low. This resolves BZ #30579. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reported-by: Nicolas Dusart <nicolas@freedelity.be> Reported-by: Aurelien Jarno <aurelien@aurel32.net> Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Aurelien Jarno <aurelien@aurel32.net> (cherry picked from commit 2fb12bbd092b0c10f1f2083216e723d2406e21c4)
* hppa: xfail debug/tst-ssp-1 when have-ssp is yes (gcc-12 and later)John David Anglin2023-07-011-0/+4
|
* io: Fix F_GETLK, F_SETLK, and F_SETLKW for powerpc64Adhemerval Zanella2023-05-311-0/+6
| | | | | | | | | | | | | | | | | | | | Different than other 64 bit architectures, powerpc64 defines the LFS POSIX lock constants with values similar to 32 ABI, which are meant to be used with fcntl64 syscall. Since powerpc64 kABI does not have fcntl, the constants are adjusted with the FCNTL_ADJUST_CMD macro. The 4d0fe291aed3a476a changed the logic of generic constants LFS value are equal to the default values; which is now wrong for powerpc64. Fix the value by explicit define the previous glibc constants (powerpc64 does not need to use the 32 kABI value, but it simplifies the FCNTL_ADJUST_CMD which should be kept as compatibility). Checked on powerpc64-linux-gnu and powerpc-linux-gnu. (cherry picked from commit 5f828ff824e3b7cd133ef905b8ae25ab8a8f3d66)
* io: Fix record locking contants on 32 bit arch with 64 bit default time_t ↵Adhemerval Zanella2023-05-305-26/+135
| | | | | | | | | | | | | | | | | | | (BZ#30477) For architecture with default 64 bit time_t support, the kernel does not provide LFS and non-LFS values for F_GETLK, F_GETLK, and F_GETLK (the default value used for 64 bit architecture are used). This is might be considered an ABI break, but the currenct exported values is bogus anyway. The POSIX lockf is not affected since it is aliased to lockf64, which already uses the LFS values. Checked on i686-linux-gnu and the new tests on a riscv32. Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 4d0fe291aed3a476a3b59c4ecfae9d35ac0f15e8)
* Document BZ #20975 fixH.J. Lu2023-05-231-0/+1
|
* __check_pf: Add a cancellation cleanup handler [BZ #20975]H.J. Lu2023-05-232-0/+17
| | | | | | | | | | | | | | | | | | | | | | There are reports for hang in __check_pf: https://github.com/JoeDog/siege/issues/4 It is reproducible only under specific configurations: 1. Large number of cores (>= 64) and large number of threads (> 3X of the number of cores) with long lived socket connection. 2. Low power (frequency) mode. 3. Power management is enabled. While holding lock, __check_pf calls make_request which calls __sendto and __recvmsg. Since __sendto and __recvmsg are cancellation points, lock held by __check_pf won't be released and can cause deadlock when thread cancellation happens in __sendto or __recvmsg. Add a cancellation cleanup handler for __check_pf to unlock the lock when cancelled by another thread. This fixes BZ #20975 and the siege hang issue. (cherry picked from commit a443bd3fb233186038b8b483959ecb7978d1abea)
* Ignore MAP_VARIABLE in tst-mman-consts.pyJoseph Myers2023-05-171-2/+5
| | | | | | | | | | | | | Linux 6.2 removed the hppa compatibility MAP_VARIABLE define. That means that, whether or not we remove it in glibc, it needs to be ignored in tst-mman-consts.py (since this macro comparison infrastructure expects that new kernel header versions only add new macros, not remove old ones). Tested with build-many-glibcs.py for hppa-linux-gnu (Linux 6.2 headers). (cherry picked from commit 01e09ab0574758e0afff4333511866278ce7c84f)
* gmon: Revert addition of tunables to the manualFlorian Weimer2023-04-281-59/+0
| | | | | These tunables had to be removed over GLIBC_PRIVATE ABI stability concerns.
* gmon: Revert addition of tunables to preserve GLIBC_PRIVATE ABIFlorian Weimer2023-04-282-29/+1
| | | | | | | | Otherwise, processes are likely to crash during concurrent updates to a new glibc version on the stable release branch. The test gmon/tst-mcount-overflow depends on those tunables, so it has to be removed as well.
* gmon: fix memory corruption issues [BZ# 30101]Simon Kissane2023-04-284-8/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V2 of this patch fixes an issue in V1, where the state was changed to ON not OFF at end of _mcleanup. I hadn't noticed that (counterintuitively) ON=0 and OFF=3, hence zeroing the buffer turned it back on. So set the state to OFF after the memset. 1. Prevent double free, and reads from unallocated memory, when _mcleanup is (incorrectly) called two or more times in a row, without an intervening call to __monstartup; with this patch, the second and subsequent calls effectively become no-ops instead. While setting tos=NULL is minimal fix, safest action is to zero the whole gmonparam buffer. 2. Prevent memory leak when __monstartup is (incorrectly) called two or more times in a row, without an intervening call to _mcleanup; with this patch, the second and subsequent calls effectively become no-ops instead. 3. After _mcleanup, treat __moncontrol(1) as __moncontrol(0) instead. With zeroing of gmonparam buffer in _mcleanup, this stops the state incorrectly being changed to GMON_PROF_ON despite profiling actually being off. If we'd just done the minimal fix to _mcleanup of setting tos=NULL, there is risk of far worse memory corruption: kcount would point to deallocated memory, and the __profil syscall would make the kernel write profiling data into that memory, which could have since been reallocated to something unrelated. 4. Ensure __moncontrol(0) still turns off profiling even in error state. Otherwise, if mcount overflows and sets state to GMON_PROF_ERROR, when _mcleanup calls __moncontrol(0), the __profil syscall to disable profiling will not be invoked. _mcleanup will free the buffer, but the kernel will still be writing profiling data into it, potentially corrupted arbitrary memory. Also adds a test case for (1). Issues (2)-(4) are not feasible to test. Signed-off-by: Simon Kissane <skissane@gmail.com> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit bde121872001d8f3224eeafa5b7effb871c3fbca)
* gmon: improve mcount overflow handling [BZ# 27576]Simon Kissane2023-04-289-7/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When mcount overflows, no gmon.out file is generated, but no message is printed to the user, leaving the user with no idea why, and thinking maybe there is some bug - which is how BZ 27576 ended up being logged. Print a message to stderr in this case so the user knows what is going on. As a comment in sys/gmon.h acknowledges, the hardcoded MAXARCS value is too small for some large applications, including the test case in that BZ. Rather than increase it, add tunables to enable MINARCS and MAXARCS to be overridden at runtime (glibc.gmon.minarcs and glibc.gmon.maxarcs). So if a user gets the mcount overflow error, they can try increasing maxarcs (they might need to increase minarcs too if the heuristic is wrong in their case.) Note setting minarcs/maxarcs too large can cause monstartup to fail with an out of memory error. If you set them large enough, it can cause an integer overflow in calculating the buffer size. I haven't done anything to defend against that - it would not generally be a security vulnerability, since these tunables will be ignored in suid/sgid programs (due to the SXID_ERASE default), and if you can set GLIBC_TUNABLES in the environment of a process, you can take it over anyway (LD_PRELOAD, LD_LIBRARY_PATH, etc). I thought about modifying the code of monstartup to defend against integer overflows, but doing so is complicated, and I realise the existing code is susceptible to them even prior to this change (e.g. try passing a pathologically large highpc argument to monstartup), so I decided just to leave that possibility in-place. Add a test case which demonstrates mcount overflow and the tunables. Document the new tunables in the manual. Signed-off-by: Simon Kissane <skissane@gmail.com> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit 31be941e4367c001b2009308839db5c67bf9dcbc)
* gmon: Fix allocated buffer overflow (bug 29444)Леонид Юрьев (Leonid Yuriev)2023-04-282-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `__monstartup()` allocates a buffer used to store all the data accumulated by the monitor. The size of this buffer depends on the size of the internal structures used and the address range for which the monitor is activated, as well as on the maximum density of call instructions and/or callable functions that could be potentially on a segment of executable code. In particular a hash table of arcs is placed at the end of this buffer. The size of this hash table is calculated in bytes as p->fromssize = p->textsize / HASHFRACTION; but actually should be p->fromssize = ROUNDUP(p->textsize / HASHFRACTION, sizeof(*p->froms)); This results in writing beyond the end of the allocated buffer when an added arc corresponds to a call near from the end of the monitored address range, since `_mcount()` check the incoming caller address for monitored range but not the intermediate result hash-like index that uses to write into the table. It should be noted that when the results are output to `gmon.out`, the table is read to the last element calculated from the allocated size in bytes, so the arcs stored outside the buffer boundary did not fall into `gprof` for analysis. Thus this "feature" help me to found this bug during working with https://sourceware.org/bugzilla/show_bug.cgi?id=29438 Just in case, I will explicitly note that the problem breaks the `make test t=gmon/tst-gmon-dso` added for Bug 29438. There, the arc of the `f3()` call disappears from the output, since in the DSO case, the call to `f3` is located close to the end of the monitored range. Signed-off-by: Леонид Юрьев (Leonid Yuriev) <leo@yuriev.ru> Another minor error seems a related typo in the calculation of `kcountsize`, but since kcounts are smaller than froms, this is actually to align the p->froms data. Co-authored-by: DJ Delorie <dj@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 801af9fafd4689337ebf27260aa115335a0cb2bc)
* posix: Fix system blocks SIGCHLD erroneously [BZ #30163]Adam Yi2023-04-288-3/+141
| | | | | | | | | | | | | | | | | | | | | | Fix bug that SIGCHLD is erroneously blocked forever in the following scenario: 1. Thread A calls system but hasn't returned yet 2. Thread B calls another system but returns SIGCHLD would be blocked forever in thread B after its system() returns, even after the system() in thread A returns. Although POSIX does not require, glibc system implementation aims to be thread and cancellation safe. This bug was introduced in 5fb7fc96350575c9adb1316833e48ca11553be49 when we moved reverting signal mask to happen when the last concurrently running system returns, despite that signal mask is per thread. This commit reverts this logic and adds a test. Signed-off-by: Adam Yi <ayi@janestreet.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit 436a604b7dc741fc76b5a6704c6cd8bb178518e7)
* x86_64: Fix asm constraints in feraiseexcept (bug 30305)Florian Weimer2023-04-242-2/+3
| | | | | | | | | | The divss instruction clobbers its first argument, and the constraints need to reflect that. Fortunately, with GCC 12, generated code does not actually change, so there is no externally visible bug. Suggested-by: Jakub Jelinek <jakub@redhat.com> Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com> (cherry picked from commit 5d1ccdda7b0c625751661d50977f3dfbc73f8eae)
* gshadow: Matching sgetsgent, sgetsgent_r ERANGE handling (bug 30151)Florian Weimer2023-04-244-2/+75
| | | | | | | | | | | | | | Before this change, sgetsgent_r did not set errno to ERANGE, but sgetsgent only check errno, not the return value from sgetsgent_r. Consequently, sgetsgent did not detect any error, and reported success to the caller, without initializing the struct sgrp object whose address was returned. This commit changes sgetsgent_r to set errno as well. This avoids similar issues in applications which only change errno. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit 969e9733c7d17edf1e239a73fa172f357561f440)
* stdio-common: tests: don't double-define _FORTIFY_SOURCESam James2023-04-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Exactly the same as 35bcb08eaa953c9b8bef6ab2486dc4361e1f26c0. If using -D_FORITFY_SOURCE=3 (in my case, I've patched GCC to add =3 instead of =2 (we've done =2 for years in Gentoo)), building glibc tests will fail on tst-bz11319-fortify2 like: ``` <command-line>: error: "_FORTIFY_SOURCE" redefined [-Werror] <built-in>: note: this is the location of the previous definition cc1: all warnings being treated as errors ``` It's just because we're always setting -D_FORTIFY_SOURCE=2 rather than unsetting it first. If F_S is already 2, it's harmless, but if it's another value (say, 1, or 3), the compiler will bawk. (I'm not aware of a reason this couldn't be tested with =3, but the toolchain support is limited for that (too new), and we want to run the tests everywhere possible.) As Siddhesh noted previously, we could implement some fallback logic to determine the maximal F_S value supported by the toolchain, which is a bit easier now that autoconf-archive has been updated for F_S=3 (https://github.com/autoconf-archive/autoconf-archive/pull/269), but let's revisit this if it continues to crop up. Signed-off-by: Sam James <sam@gentoo.org> Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit ecf8ae6704d5034fc2d5e29e5dc88dbca981581e)
* elf: Restore ldconfig libc6 implicit soname logic [BZ #30125]Joan Bruguera2023-02-208-23/+69
| | | | | | | | | | | | | | | | | | | | | | | While cleaning up old libc version support, the deprecated libc4 code was accidentally kept in `implicit_soname`, instead of the libc6 code. This causes additional symlinks to be created by `ldconfig` for libraries without a soname, e.g. a library `libsomething.123.456.789` without a soname will create a `libsomething.123` -> `libsomething.123.456.789` symlink. As the libc6 version of the `implicit_soname` code is a trivial `xstrdup`, just inline it and remove `implicit_soname` altogether. Some further simplification looks possible (e.g. the call to `create_links` looks like a no-op if `soname == NULL`, other than the verbose printfs), but logic is kept as-is for now. Fixes: BZ #30125 Fixes: 8ee878592c4a ("Assume only FLAG_ELF_LIBC6 suport") Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit 1b0ea8c5d886fedabd611a569b5ec58a6f5153e6)
* stdlib: Undo post review change to 16adc58e73f3 [BZ #27749]Vitaly Buka2023-02-203-2/+81
| | | | | | | | | | | Post review removal of "goto restart" from https://sourceware.org/pipermail/libc-alpha/2021-April/125470.html introduced a bug when some atexit handers skipped. Signed-off-by: Vitaly Buka <vitalybuka@google.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit fd78cfa72ea2bab30fdb4e1e0672b34471426c05)
* elf: Smoke-test ldconfig -p against system /etc/ld.so.cacheFlorian Weimer2023-02-082-0/+83
| | | | | | | | | The test is sufficient to detect the ldconfig bug fixed in commit 9fe6f6363886aae6b2b210cae3ed1f5921299083 ("elf: Fix 64 time_t support for installed statically binaries"). Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 9fd63e35371b9939e9153907c6a753e6960b68ad)
* NEWS: Document CVE-2023-25139.Carlos O'Donell2023-02-071-0/+9
| | | | | Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit 67c37737ed474d25fd4dc535dfd822c426e6b971)
* Account for grouping in printf width (bug 30068)Carlos O'Donell2023-02-073-5/+73
| | | | | | | | | | This is a partial fix for mishandling of grouping when formatting integers. It properly computes the width in the presence of grouping characters when the width is larger than the number of significant digits. The precision related issue is documented in bug 23432. Co-authored-by: Andreas Schwab <schwab@suse.de> (cherry picked from commit c980549cc6a1c03c23cc2fe3e7b0fe626a0364b0)
* Use 64-bit time_t interfaces in strftime and strptime (bug 30053)Andreas Schwab2023-02-076-2/+68
| | | | | | Both functions use time_t only internally, so the ABI is not affected. (cherry picked from commit 41349f6f67c83e7bafe49f985b56493d2c4c9c77)
* LoongArch: Add new relocation types.caiyinyu2023-02-031-0/+40
|
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-05-19 21:20:32 +0000