Bug 2065675

Summary: glibc: Memory leak in _dl_find_object_update
Product: [Fedora] Fedora Reporter: Pavel Březina <pbrezina>
Component: glibcAssignee: Florian Weimer <fweimer>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 36CC: aoliva, arjun, codonell, dj, fweimer, law, mcermak, mfabian, pfrankli, rth, sipoyare
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: glibc-2.35-5.fc36 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-05-10 13:11:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
valgrind logs none

Description Pavel Březina 2022-03-18 12:57:26 UTC 
Created attachment 1866598 [details]
valgrind logs

When running sssd test suits (dlopen-tests [1]), we hit the attached valgrind error. This is on Fedora 36 and 37.

[1] https://github.com/SSSD/sssd/blob/master/src/tests/dlopen-tests.c

==399173== 0 bytes in 2 blocks are definitely lost in loss record 1 of 11
==399173==    at 0x484586F: malloc (vg_replace_malloc.c:381)
==399173==    by 0x4005564: UnknownInlinedFun (rtld-malloc.h:56)
==399173==    by 0x4005564: _dl_find_object_update (dl-find_object.c:791)
==399173==    by 0x400DCF7: dl_open_worker_begin (dl-open.c:735)
==399173==    by 0x49C58ED: _dl_catch_exception (dl-error-skeleton.c:208)
==399173==    by 0x400D289: dl_open_worker (dl-open.c:782)
==399173==    by 0x49C58ED: _dl_catch_exception (dl-error-skeleton.c:208)
==399173==    by 0x400D67B: _dl_open (dl-open.c:883)
==399173==    by 0x48FA239: dlopen_doit (dlopen.c:56)
==399173==    by 0x49C58ED: _dl_catch_exception (dl-error-skeleton.c:208)
==399173==    by 0x49C59A2: _dl_catch_error (dl-error-skeleton.c:227)
==399173==    by 0x48F9D3E: _dlerror_run (dlerror.c:138)
==399173==    by 0x48FA2D7: dlopen_implementation (dlopen.c:71)
==399173==    by 0x48FA2D7: dlopen@@GLIBC_2.34 (dlopen.c:81)
==399173== 
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: definite
   fun:malloc
   fun:UnknownInlinedFun
   fun:_dl_find_object_update
   fun:dl_open_worker_begin
   fun:_dl_catch_exception
   fun:dl_open_worker
   fun:_dl_catch_exception
   fun:_dl_open
   fun:dlopen_doit
   fun:_dl_catch_exception
   fun:_dl_catch_error
   fun:_dlerror_run
   fun:dlopen_implementation
   fun:dlopen@@GLIBC_2.34
}
Comment 1 Florian Weimer 2022-03-18 13:54:44 UTC 
Huh. I see one obvious leak:

diff --git a/elf/dl-find_object.c b/elf/dl-find_object.c
index 2b8df2fd67..b9094a0e17 100644
--- a/elf/dl-find_object.c
+++ b/elf/dl-find_object.c
@@ -798,7 +798,10 @@ _dl_find_object_update (struct link_map *new_map)
         map_array[i++] = l;
   }
   if (count == 0)
-    return true;
+    {
+      free (map_array);
+      return true;
+    }
 
   _dl_find_object_link_map_sort (map_array, count);
   bool ok = _dl_find_object_update_1 (map_array, count);

However, I'm not quite sure how to reach this code path. Can you put a conditional breakpoint on the if statement for the count == 0 condition, and see what new_map->l_name is at this point? Thanks.
Comment 2 Pavel Březina 2022-03-21 13:42:18 UTC 
Hi, you can get it in gdb like this:

# prepare environment
$ podman run --cap-add SYS_ADMIN --cap-add SYS_PTRACE --security-opt seccomp=unconfined --name test --detach quay.io/sssd/ci-client-devel:fedora-36 &&
  podman exec -u ci --workdir /home/ci test git clone https://github.com/SSSD/sssd &&
  podman exec -u ci --workdir /home/ci/sssd test sudo ./contrib/ci/run --deps-only &&
  podman exec -u ci --workdir /home/ci/sssd test /bin/bash -c 'autoreconf -if && ./configure && make && make check'

# run test in valgrind
$ podman exec -u ci --workdir /home/ci/sssd test valgrind --leak-check=full ./dlopen-tests

# get gdb
$ podman exec -u ci --workdir /home/ci/sssd test /bin/bash -c 'CK_FORK=no gdb ./dlopen-tests'
Comment 3 Florian Weimer 2022-04-13 12:11:40 UTC 
The last command needs to be:

podman exec -i -t -u ci --workdir /home/ci/sssd test /bin/bash -c 'CK_FORK=no gdb ./dlopen-tests'

And it only works in SELinux permissive mode.

Nevertheless, I have convinced myself that I know understand what is going on, despite unrelated debugging troubles (bug 2074993). I'll fix this upstream and backport.
Comment 4 Fedora Update System 2022-04-13 18:28:44 UTC 
FEDORA-2022-35a1f6fbb0 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-35a1f6fbb0
Comment 5 Fedora Update System 2022-04-13 19:49:39 UTC 
FEDORA-2022-35a1f6fbb0 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-35a1f6fbb0`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-35a1f6fbb0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 7 Fedora Update System 2022-05-07 04:24:00 UTC 
FEDORA-2022-35a1f6fbb0 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.