Automatic update for glibc-2.38.9000-21.fc40.
* Sat Nov 11 2023 Florian Weimer <fweimer@redhat.com> - 2.38.9000-21
- Fix missing entries in /etc/ld.so.cache (#2248915)
* Sat Nov 11 2023 Florian Weimer <fweimer@redhat.com> - 2.38.9000-20
- Drop glibc-rh2248502-*.patch, workaround applied upstream
- Auto-sync with upstream branch master,
commit d1dcb565a1fb5829f9476a1438c30eccc4027d04:
- Fix type typo in “String/Array Conventions” doc
- stdlib: Avoid element self-comparisons in qsort (#2248502)
- elf: Add glibc.mem.decorate_maps tunable
- linux: Decorate __libc_fatal error buffer
- assert: Decorate error message buffer
- malloc: Decorate malloc maps
- nptl: Decorate thread stack on pthread_create
- support: Add support_set_vma_name
- linux: Add PR_SET_VMA_ANON_NAME support
Automatic update for glibc-2.38.9000-20.fc40.
Please login to add feedback.
This update was automatically created
This update has obsoleted glibc-2.38.9000-20.fc40, and has inherited its bugs and notes.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
this is causing ns-slapd to crash in FreeIPA tests. I'm back from vacation and will look into it in more detail and try to get a backtrace.
Here's the backtrace I was able to get:
This happens during FreeIPA server deployment. It seems like ns-slapd gets started up, shut down and started up again several times during server deployment. This happens at the "[7/10]: upgrading server" stage of the process.
Thanks. The comparison function can never return zero: https://github.com/389ds/389-ds-base/blob/main/ldap/servers/plugins/cos/cos_cache.c#L2933
This is clearly a
389-ds-base
bug. The oldqsort
implementation in glibc did not tickle it because it rarely called the comparison function with equal pointer arguments. We already worked around similar application problems in other places in the new implementation, we can probably do it in the insertion sort phase as well.This update has been obsoleted by glibc-2.38.9000-22.fc40.
The crash occurs in cos_cache:2924 on that line
The only reason of the crash would be the dereferenced pAttr1. It exists a known heap corruption bug (https://github.com/389ds/389-ds-base/issues/5984) that was not fixed in the Rawhide version of the DS that was tested. This ticket is now fixed. It is highly probable that the crash was due to #5984.
I agree that cos_cache_attr_compare can not return a 0 (equal). It is not a problem for DS to force an arbitrary sorting rather than letting qsort decide. I do not see why not returning 0 would crash in that routine
Before the workaround, glibc had this loop:
https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/qsort.c;h=ad110e8a892a66e1fc90f850b828e1a2d09e2ac5;hb=HEAD#l220
The loop is known to terminate if the comparison function is correct because eventually,
run_ptr == tmp_ptr
, andcmp
must return zero. If that never happens, we eventually run into non-allocated memory regions. The only access to that memory is from thecmp
function here, not from theqsort
implementation, so that crash will happen in the comparison callback.Okay I agree with your explanations. The loop overrun the buffer and make the cmp function sigsev.
I created https://github.com/389ds/389-ds-base/issues/5992 to track this issue.