This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dlmopen in LD_PRELOAD


Hi Florian,

(re-send because previous email failed to send due to attachment)

I made a tiny project this issue, it didn't show the same failure, however
it did segfaults inside the library being `dlmopen`-ed.

link: `git clone https://github.com/wangbj/dlns-test.git`
(sorry attachment seems to cause failure to send message)

run.c: an launcher to inject DSOs.
preload.c: a mini loader using LD_PRELOAD -> dlmopen
dlns.c: DSO being `dlmopen`-ed
app.c: app being injected with DSOs.

running `make test` should reproduce the issue. (need to run `ulimit -c
unlimited` to get core dump).

In app.c, it used manual symbol lookups to find symbols in libdlns.so
(built from dlns.c), so it might have broken the total isolation
assumption, maybe this isn't something suppose to happen?

Thanks

On Mon, Jun 17, 2019 at 3:02 PM Florian Weimer <fweimer@redhat.com> wrote:

> * Baojun Wang:
>
> >> Does the library you load via dlmopen contain its own definition of
> >> malloc, perhaps indirectly?
> >
> > I don't think so, though the dynamic library does depends on libc.so.
>
> The malloc loaded from glibc's libc.so.6 should work in this scenario,
> and we have tests for basic dlmopen usage to prove this.
>
> > Also worth mentioning is if I manually patch `__get_nprocs`, which is
> > called `area_get2`, then I can see the stack overflow any longer. the
> > pseudo assembly used to patch `__get_nprocs`:
>
> Hmm.  Do you have a small reproducer which only uses C libraries?
>
> Thanks,
> Florian
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]