Bug ID: 16272
Summary: dlopen()ing a DT_FILTER library crashes if filtee has
Assignee: unassigned at sourceware dot org
Reporter: brnguyen at nvidia dot com
The attached test case loads a DSO which has a DT_FILTER set to a shared
object with a constructor function. This segfaults on RHEL 6.4, and on an
ld.so built from commit a9503496671bb22278bd1203182066f0bb28239a, this
crashes with the following assertion:
Author: David Kilroy <[hidden email]>
Date: Wed Feb 12 14:28:15 2020 -0300
elf: Allow dlopen of filter object to work [BZ #16272]
There are two fixes that are needed to be able to dlopen filter
objects. First _dl_map_object_deps cannot assume that map will be at
the beginning of l_searchlist.r_list, as filtees are inserted before
map. Secondly dl_open_worker needs to ensure that filtees get
* avoiding removing relocation dependencies of map by setting
l_reserved to 0 and otherwise processing the rest of the search
* ensure that map remains at the beginning of l_initfini - the list
of things that need initialisation (and destruction). Do this by
splitting the copy up. This may not be required, but matches the
initialization order without dlopen.
Modify dl_open_worker to relocate the objects in new->l_inifini.
new->l_initfini is constructed in _dl_map_object_deps, and lists the
objects that need initialization and destruction. Originally the list
of objects in new->l_next are relocated. All of these objects should
also be included in new->l_initfini (both lists are populated with
dependencies in _dl_map_object_deps). We can't use new->l_prev to pick
up filtees, as during a recursive dlopen from an interposed malloc
call, l->prev can contain objects that are not ready for relocation.
Add tests to verify that symbols resolve to the filtee implementation
when auxiliary and filter objects are used, both as a normal link and
Tested by running the testsuite on x86_64.
You are receiving this mail because:
You are on the CC list for the bug.