[Bug dynamic-link/16628] New: Segfault after a binary without pthread dlopen()s a library linked with pthread

[Bug dynamic-link/16628] New: Segfault after a binary without pthread dlopen()s a library linked with pthread

[tudorb at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16628

            Bug ID: 16628
           Summary: Segfault after a binary without pthread dlopen()s a
                    library linked with pthread
           Product: glibc
           Version: 2.12
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: tudorb at gmail dot com

If the main executable is linked without pthread dlopen()s a shared library
linked with pthread, it causes a memory corruption in the dynamic loader. When
a symbol resolution fails afterwards, you get a segfault rather than a message
on stderr (and clean _exit()).

Explanation:

When the main executable is linked without pthread and it dlopen()s s shared
library linked with pthread, pthread initialization
(__pthread_initialize_minimal_internal) happens during loading, with a dynamic
loader error handler (_dl_catch_error) on the stack.

__pthread_initialize_minimal_internal switches the location of the error
handling jmp_buf (returned by the function at _dl_error_catch_tsd) from the
non-thread-aware one (_dl_initial_error_catch_tsd) to the thread-aware one
(__libc_dl_error_tsd). It also copies the location of the current error
handling buffer, if any, to the thread-specific version. As _dl_catch_error is
on the stack at this point, we store the address of that error handling jmp_buf
into the thread-specific location.

After __pthread_initialize_minimal_internal returns, control eventually reaches
back to _dl_catch_error, which is supposed to restore the previous handler
(which should be NULL). But it restores the previous handler into the wrong
location -- it restores it where it saved it from (the global,
not-thread-specific, location, as returned by _dl_initial_error_catch_tsd), and
we're using the thread-specific location now.

So the thread-specific location now contains garbage. Next time we try to
signal an error from a dl* function, we try to longjmp to that garbage, and we
segfault.

Steps to reproduce (also see attached files):

- create a shared library that has an unresolved symbol and links with pthread
- from a main executable that links without pthread, dlopen the shared library
with RTLD_LAZY
- force the unresolved symbol from the shared library to be resolved.

Attached: a .zip with three files:

b.c: shared library
main.c: main program
mk: script to build them

Tested on 2.12 and 2.17.1.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/16628] Segfault after a binary without pthread dlopen()s a library linked with pthread

[tudorb at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16628

--- Comment #1 from Tudor Bosman <tudorb at gmail dot com> ---
Created attachment 7434
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7434&action=edit
test case

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/16628] Segfault after a binary without pthread dlopen()s a library linked with pthread

[tudorb at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16628

Tudor Bosman <tudorb at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|2.12                        |2.17

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/16628] Segfault after a binary without pthread dlopen()s a library linked with pthread

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=16628

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
My understanding is that this usage is explicitly unsupported. However, if
that's the case, it should fail cleanly (with the error message in dlerror)
rather than crashing or exiting the program so I believe this bug report is
valid.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/16628] Segfault after a binary without pthread dlopen()s a library linked with pthread

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16628

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #2)
> My understanding is that this usage is explicitly unsupported. However, if
> that's the case, it should fail cleanly (with the error message in dlerror)
> rather than crashing or exiting the program so I believe this bug report is
> valid.

My understanding was, and we have tests in the testsuite to test this, that
dlopening libpthread is allowed. Why would we disallow this? I think this is
just a case where we have missed fixing things up for the transition from
unthreaded to threaded.

Notes:
- See nptl/tst-unload.c.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/16628] Segfault after a binary without pthread dlopen()s a library linked with pthread

[amonakov at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16628

Alexander Monakov <amonakov at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amonakov at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/16628] Segfault after a binary without pthread dlopen()s a library linked with pthread

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16628

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Carlos O'Donell from comment #3)
> (In reply to Rich Felker from comment #2)
> > My understanding is that this usage is explicitly unsupported. However, if
> > that's the case, it should fail cleanly (with the error message in dlerror)
> > rather than crashing or exiting the program so I believe this bug report is
> > valid.
> 
> My understanding was, and we have tests in the testsuite to test this, that
> dlopening libpthread is allowed. Why would we disallow this?

The pthread_mutex_init stub in libc.so.6 does nothing, so the mutex will
contain garbage.  This works fine as long as only the stubbed version of
pthread_mutex_lock is used (which also does nothing).  But the process will
crash once the stubs are replaced with the real thing because libpthread.so.0
has been loaded into the process.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/16628] Segfault after a binary without pthread dlopen()s a library linked with pthread

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16628

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security?

-- 
You are receiving this mail because:
You are on the CC list for the bug.