[Bug dynamic-link/13862] New: Reuse of cached stack can cause bounds overrun of thread DTV

[Bug dynamic-link/13862] New: Reuse of cached stack can cause bounds overrun of thread DTV

[paul at vineyardnetworks dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13862

             Bug #: 13862
           Summary: Reuse of cached stack can cause bounds overrun of
                    thread DTV
           Product: glibc
           Version: 2.14
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
        AssignedTo: unassigned@sourceware.org
        ReportedBy: paul@vineyardnetworks.com
    Classification: Unclassified


Created attachment 6290
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6290
Small program that demonstrates the issue

Platform: Linux/x86_64 (multiple versions including Ubuntu 10, 12, Fedora core
14, Centos 5.5+)

GLIBC versions: tested with 2.7, 2.9, 2.11, 2.14 built from official source

In a program satisfying the conditions listed below, reusing a cached stack
causes a bounds overrun of the thread's DTV structure, leading to a probable
crash.  The _dl_allocate_tls_init function re-initializes the dtv based on the
current slotinfo_list, however it is possible for the dtv to be smaller than
the highest module id loaded.  When this happens the function will write over
memory outside of the dtv, leading to unpredictable behavior and an eventual
crash.

See proposed fix below and attached test-case for repro.

Conditions needed:

The use of a relatively large number of dynamic libraries, loaded at runtime
using dlopen

The use of thread-local-storage within those libraries

A thread exiting prior to the number of loaded libraries increasing a
significant amount, followed by a new thread being created after the number of
libraries has increased.

Example Valgrind output:

==27966== Invalid write of size 8
==27966==    at 0x4010A7A: _dl_allocate_tls_init (dl-tls.c:418)
==27966==    by 0x4E35294: pthread_create@@GLIBC_2.2.5 (allocatestack.c:252)

followed by:
==27966==  Address 0x5b4e6d0 is 0 bytes after a block of size 304 alloc'd
==27966==    at 0x4C26D85: calloc (vg_replace_malloc.c:566)
==27966==    by 0x4010439: allocate_dtv (dl-tls.c:297)
==27966==    by 0x4010B4D: _dl_allocate_tls (dl-tls.c:461)
==27966==    by 0x4E357E9: pthread_create@@GLIBC_2.2.5 (allocatestack.c:575)

Proposed fix:

*** dl-tls.c    2011-05-30 21:12:33.000000000 -0700
--- ../../glibc-2.14.orig/elf/dl-tls.c    2012-03-13 11:29:27.172794002 -0700
***************
*** 406,411 ****
--- 406,415 ----
          /* Unused entry.  */
          continue;

+       /* make sure we don't overrun the currently allocated dtv */
+       if (map->l_tls_modid >= dtv[-1].counter)
+           continue;
+ 
        /* Keep track of the maximum generation number.  This might
           not be the generation counter.  */
        maxgen = MAX (maxgen, listp->slotinfo[cnt].gen);
***************
*** 599,605 ****
          {
            /* If this modid was used at some point the memory
               might still be allocated.  */
!           if (! dtv[total + cnt].pointer.is_static
                && dtv[total + cnt].pointer.val != TLS_DTV_UNALLOCATED)
              {
                free (dtv[total + cnt].pointer.val);
--- 603,609 ----
          {
            /* If this modid was used at some point the memory
               might still be allocated.  */
!           if (total + cnt < dtv[-1].counter && !dtv[total +
cnt].pointer.is_static
                && dtv[total + cnt].pointer.val != TLS_DTV_UNALLOCATED)
              {
                free (dtv[total + cnt].pointer.val);


Reproduction/test case attached.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[paul at vineyardnetworks dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13862

--- Comment #1 from Paul Archard <paul at vineyardnetworks dot com> 2012-03-16 23:01:57 UTC ---
An alternative fix would be the following - it is possibly a more complete fix
but it does break encapsulation a little.  The previous suggested fix relies on
the dtv being fixed up later.

*** dl-tls.c    2011-05-30 21:12:33.000000000 -0700
--- ../../glibc-2.14.orig/elf/dl-tls.c    2012-03-12 14:37:27.422794007 -0700
***************
*** 35,48 ****


  /* Out-of-memory handler.  */
- #ifdef SHARED
  static void
  __attribute__ ((__noreturn__))
  oom (void)
  {
    _dl_fatal_printf ("cannot allocate memory for thread-local data: ABORT\n");
  }
- #endif


  size_t
--- 35,46 ----
***************
*** 388,393 ****
--- 386,437 ----
       TLS.  For those which are dynamically loaded we add the values
       indicating deferred allocation.  */
    listp = GL(dl_tls_dtv_slotinfo_list);
+ 
+   /* check if current dtv is big enough */
+   if (dtv[-1].counter < GL(dl_tls_max_dtv_idx))
+   {
+     dtv_t *newp;
+     size_t newsize = GL(dl_tls_max_dtv_idx) + DTV_SURPLUS;
+     size_t oldsize = dtv[-1].counter;
+       
+     if (
+ #ifdef SHARED
+         dtv == GL(dl_initial_dtv)
+ #else
+         0
+ #endif
+         )
+     {
+       /* This is the initial dtv that was allocated
+       during rtld startup using the dl-minimal.c
+       malloc instead of the real malloc.  We can't
+       free it, we have to abandon the old storage.  */
+       newp = malloc ((2 + newsize) * sizeof (dtv_t));
+       if (newp == NULL)
+         oom ();
+       memcpy (newp, &dtv[-1], (2 + oldsize) * sizeof (dtv_t));
+     }
+     else
+     {
+       newp = realloc(&dtv[-1], (2 + newsize) * sizeof (dtv_t));
+       if (newp == NULL)
+         oom();
+     }
+ 
+     newp[0].counter = newsize;
+ 
+     /* Clear the newly allocated part.  */
+     memset (newp + 2 + oldsize, '\0', (newsize - oldsize) * sizeof (dtv_t));
+ 
+     /* Point dtv to the generation counter.  */
+     dtv = &newp[1];
+ 
+     /* Install this new dtv in the given thread */
+     INSTALL_DTV (result, newp);
+   
+     assert(dtv[-1].counter >= GL(dl_tls_max_dtv_idx));
+   }
+ 
    while (1)
      {
        size_t cnt;

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[ppluzhnikov at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13862

Paul Pluzhnikov <ppluzhnikov at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppluzhnikov at google dot
                   |                            |com
            Version|2.14                        |unspecified

--- Comment #2 from Paul Pluzhnikov <ppluzhnikov at google dot com> 2012-03-18 00:02:13 UTC ---
Confirmed present in current git trunk.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[foelsche at sbcglobal dot net]

http://sourceware.org/bugzilla/show_bug.cgi?id=13862

Peter Foelsche <foelsche at sbcglobal dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |foelsche at sbcglobal dot
                   |                            |net

--- Comment #3 from Peter Foelsche <foelsche at sbcglobal dot net> 2012-05-01 00:01:56 UTC ---
I wrote pthread_key_create(), pthread_key_delete (), pthread_getspecific (),
pthread_setspecific()

and an empty

_dl_allocate_tls_init()

and it seems to be working.
All this is using an 

typedef std::map<pthread_t, void *> CThread2VoidStar;
typedef std::map<pthread_key_t, CThread2VoidStar> CKey2Thread2VoidStar;

and a spinlock to protect against parallel access.
I'm not following what loaded dlls have to do with this.
53 lines of code...

I ignored the parameter
void (*__destr_function) (void *)
for now -- but this would also be pretty easy.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[paul at vineyardnetworks dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13862

--- Comment #4 from Paul Archard <paul at vineyardnetworks dot com> 2012-06-14 23:58:57 UTC ---
@Peter Foelsche:

I'm not sure you understand the problem I'm describing.  The attached test case
will crash, and the valgrind output should be easily repeatable.  You should
also be able to see by inspection that the code does not respect the size of
the container it is overwriting and can write over the end of its allocated
size.

If you have questions about the bug please feel free to email me directly.  It
is trivial to fix using the first patch I supplied (the second patch doesn't
fully fix the problem).  It would be really good to get this into the next
release as it significantly impacts anyone using TLS and dlopen together.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[siddhesh at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13862

Siddhesh Poyarekar <siddhesh at redhat dot com> changed:

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

--- Comment #5 from Siddhesh Poyarekar <siddhesh at redhat dot com> 2012-10-19 11:48:15 UTC ---
Please post the patch on libc-alpha for review.  You will need the following
guidelines for posting:

http://sourceware.org/glibc/wiki/Contribution%20checklist

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[neleai at seznam dot cz]

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

Ondrej Bilka <neleai at seznam dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |neleai at seznam dot cz

--- Comment #6 from Ondrej Bilka <neleai at seznam dot cz> ---
Was this patch posted?

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[myungjoo.ham at samsung dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13862

MyungJoo Ham <myungjoo.ham at samsung dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |myungjoo.ham at samsung dot com

--- Comment #7 from MyungJoo Ham <myungjoo.ham at samsung dot com> ---
(In reply to Ondrej Bilka from comment #6)
> Was this patch posted?

As it seems that the patch was not even made to the mailing list, I've posted.
We have been experiencing crashes related with this issue recently as well.

http://sourceware.org/ml/libc-alpha/2013-11/msg00759.html

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov <david.abdurachmanov at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david.abdurachmanov at gmail dot c
                   |                            |om

--- Comment #8 from David Abdurachmanov <david.abdurachmanov at gmail dot com> ---
I have noticed deadlock in our application on aarch64 (ARMv8 64-bit) on Fedora
19, glibc 2.17.

Our main application uses jemalloc, but on aarch64 we used glibc malloc
implementation. I found that this happens also on x86_64 with glibc used, but
not with jemalloc. x86_64 machine is running Scientific Linux 6.5 (RHEL 6.5)
with glibc 2.12.

valgrind results from x86_64:

==28032== Invalid write of size 8
==28032==    at 0x3AF1811000: _dl_allocate_tls_init (in /lib64/ld-2.12.so)
==28032==    by 0x3AF2406C20: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.12.so)
==28032==    by 0x26A0A995: XrdSysThread::Run(unsigned long*, void* (*)(void*),
void*, int, char const*) (in
/afs/cern.ch/cms/sw/ReleaseCandidates/vol1/slc6_amd64_gcc490/external/xr
ootd/3.2.4-cms2/lib/libXrdUtils.so.1.0.0)

==28032== Invalid write of size 1
==28032==    at 0x3AF1811013: _dl_allocate_tls_init (in /lib64/ld-2.12.so)
==28032==    by 0x3AF2406C20: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.12.so)
==28032==    by 0x26A0A995: XrdSysThread::Run(unsigned long*, void* (*)(void*),
void*, int, char const*) (in
/afs/cern.ch/cms/sw/ReleaseCandidates/vol1/slc6_amd64_gcc490/external/xrootd/3.2.4-cms2/lib/libXrdUtils.so.1.0.0)

I compiler plain 2.12 (origin/release/2.12/master) with debug information and
used new ld.so with valgrind:

==17333== Invalid write of size 8
==17333==    at 0x118521: _dl_allocate_tls_init (dl-tls.c:421)
==17333==    by 0x84BF29F: pthread_create@@GLIBC_2.2.5 (allocatestack.c:247)
==17333==    by 0x2803B995: XrdSysThread::Run(unsigned long*, void* (*)(void*),
void*, int, char const*) (in
/afs/cern.ch/cms/sw/ReleaseCandidates/vol1/slc6_amd64_gcc490/external/xr
ootd/3.2.4-cms2/lib/libXrdUtils.so.1.0.0)

==17333== Invalid write of size 1
==17333==    at 0x118534: _dl_allocate_tls_init (dl-tls.c:422)
==17333==    by 0x84BF29F: pthread_create@@GLIBC_2.2.5 (allocatestack.c:247)
==17333==    by 0x2803B995: XrdSysThread::Run(unsigned long*, void* (*)(void*),
void*, int, char const*) (in
/afs/cern.ch/cms/sw/ReleaseCandidates/vol1/slc6_amd64_gcc490/external/xr
ootd/3.2.4-cms2/lib/libXrdUtils.so.1.0.0)


416           if (map->l_tls_offset == NO_TLS_OFFSET
417               || map->l_tls_offset == FORCED_DYNAMIC_TLS_OFFSET)
418             {
419               /* For dynamically loaded modules we simply store
420                  the value indicating deferred allocation.  */
421               dtv[map->l_tls_modid].pointer.val = TLS_DTV_UNALLOCATED;
422               dtv[map->l_tls_modid].pointer.is_static = false;
423               continue;
424             }

421 and 422 lines. Is map->l_tls_modid correct?

So far I have not seen these invalid writes if jemalloc is used instead of
glibc.

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[david.abdurachmanov at gmail dot com]

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

--- Comment #9 from David Abdurachmanov <david.abdurachmanov at gmail dot com> ---
Forgot to mention.

Software with jemalloc passed fine, but with my compiled debug glibc:

*** glibc detected ***
/afs/cern.ch/cms/sw/ReleaseCandidates/vol1/slc6_amd64_gcc490/cms/cmssw/CMSSW_7_2_X_2014-06-06-0200/bin/slc6_amd64_gcc490/cmsRunGlibC:
corrupted double-linked
list: 0x00007f809242cb50 ***

at expected crash location.

I will attempt to test master of glibc.

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[david.abdurachmanov at gmail dot com]

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

--- Comment #10 from David Abdurachmanov <david.abdurachmanov at gmail dot com> ---
Could not test master on RHEL 6 as it doesn't compile.

Not sure if I understood code correctly, but added

diff --git a/elf/dl-tls.c b/elf/dl-tls.c
index 824adc1..aa9f3c8 100644
--- a/elf/dl-tls.c
+++ b/elf/dl-tls.c
@@ -418,6 +418,11 @@ _dl_allocate_tls_init (void *result)
            {
              /* For dynamically loaded modules we simply store
                 the value indicating deferred allocation.  */
+             _dl_printf ("dtv[-1].counter: %u\n", dtv[-1].counter);
+             _dl_printf ("map->l_tls_modid: %u\n", map->l_tls_modid);
+             _dl_printf ("map->l_origin: %s\n", map->l_origin);
+             _dl_printf ("map->l_name: %s\n", map->l_name);
+             assert (map->l_tls_modid <= dtv[-1].counter);
              dtv[map->l_tls_modid].pointer.val = TLS_DTV_UNALLOCATED;
              dtv[map->l_tls_modid].pointer.is_static = false;
              continue;

dtv[-1].counter: 50
map->l_tls_modid: 51
map->l_origin:
/afs/cern.ch/cms/sw/ReleaseCandidates/vol1/slc6_amd64_gcc490/cms/cmssw-patch/CMSSW_7_2_X_2014-06-06-1400/external/slc6_amd64_gcc490/lib
map->l_name:
/afs/cern.ch/cms/sw/ReleaseCandidates/vol1/slc6_amd64_gcc490/cms/cmssw-patch/CMSSW_7_2_X_2014-06-06-1400/external/slc6_amd64_gcc490/lib/libsiscone_spherical.so.0
Inconsistency detected by ld.so: dl-tls.c: 425: _dl_allocate_tls_init:
Assertion `map->l_tls_modid <= dtv[-1].counter' failed!

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[giulio.eulisse at gmail dot com]

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

Giulio Eulisse <giulio.eulisse at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |giulio.eulisse at gmail dot com

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[fweimer at redhat dot com]

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

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.

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[trt at alumni dot duke.edu]

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

Tom Truscott <trt at alumni dot duke.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trt at alumni dot duke.edu

--- Comment #11 from Tom Truscott <trt at alumni dot duke.edu> ---
Our application is encountering this same problem, and we need an
application-level work-around (or hack-around if necessary).  Suggestions?

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[david.abdurachmanov at gmail dot com]

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

--- Comment #12 from David Abdurachmanov <david.abdurachmanov at gmail dot com> ---
The following seems to resolve it on SLC6/CentOS6/RHEL6 and it does pass the
testcase in this bug report. However, it doesn't work well on newer versions of
glibc. It's the original Paul Archard with modifications to have
pthread_create() and dlopen() thread safe. This is needed because you might end
up opening another DSOs with TLS right after you expanded DTV and still hit the
issue.

https://github.com/davidlt/glibc-2.12-slc6/commit/31f3c8e59749ef5f77853ec2d5c019e48bdcd645

I will attempt to debug it on Fedora 21 at some point.

E.g., musl also has pthread_create() and dlopen() thread safe.

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[paul at vineyardnetworks dot com]

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

--- Comment #13 from Paul Archard <paul at vineyardnetworks dot com> ---
@Tom Truscott

One simple workaround is to specify a user-created stack for new threads using
pthread_attr_setstack().  This forces the new stack to be fully initialized
each time.

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unspecified                 |2.21
           Assignee|unassigned at sourceware dot org   |hjl.tools at gmail dot com
   Target Milestone|---                         |2.21

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, hjl/pr13862 has been created
        at  b811f571b5604f84c84d5b96394e6b892e05d14f (commit)

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b811f571b5604f84c84d5b96394e6b892e05d14f

commit b811f571b5604f84c84d5b96394e6b892e05d14f
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Thu Nov 27 05:42:23 2014 -0800

    Reallocate DTV if the current DTV isn't big enough

    This patch reallocates DTV if the current DTV isn't big enough, using
    the similar approach in _dl_update_slotinfo.  Tested on X86-64, x32
    and ia32.

        [BZ #13862]
        * elf/dl-tls.c (oom): Remove #ifdef SHARED/#endif.
        (_dl_static_dtv, _dl_initial_dtv): Moved before ...
        (_dl_allocate_tls_init): This.  Reallocate DTV if the current
        DTV isn't big enough.
        * nptl/Makefile (tests): Add tst-stack4.
        (modules-names): Add tst-stack4mod.
        ($(objpfx)tst-stack4): New.
        (tst-stack4mod.sos): Likewise.
        ($(objpfx)tst-stack4.out): Likewise.
        ($(tst-stack4mod.sos)): Likewise.
        (clean): Likewise.
        * nptl/tst-stack4.c: New file.
        * nptl/tst-stack4mod.c: Likewise.

-----------------------------------------------------------------------

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[david.abdurachmanov at gmail dot com]

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

--- Comment #15 from David Abdurachmanov <david.abdurachmanov at gmail dot com> ---
Just to make sure. dlopen() and pthread_create() is still not thread-safe and
issue might happen in heavy threading environment?

I had a case where just expanded DVT was already too small. More threads in
parallel dlopen'ing DSOs with TLS segments, while others being created.

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[hjl.tools at gmail dot com]

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

--- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to David Abdurachmanov from comment #15)
> Just to make sure. dlopen() and pthread_create() is still not thread-safe
> and issue might happen in heavy threading environment?
> 
> I had a case where just expanded DVT was already too small. More threads in
> parallel dlopen'ing DSOs with TLS segments, while others being created.

That is true. But it is a separate issue.

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, hjl/pr13862 has been created
        at  220d769f14eccf1ef36862b294cffee5ae615a74 (commit)

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=220d769f14eccf1ef36862b294cffee5ae615a74

commit 220d769f14eccf1ef36862b294cffee5ae615a74
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Thu Nov 27 05:42:23 2014 -0800

    Reallocate DTV if the current DTV isn't big enough

    This patch reallocates DTV if the current DTV isn't big enough, using
    the similar approach in _dl_update_slotinfo.  Tested on X86-64, x32
    and ia32.

        [BZ #13862]
        * elf/dl-tls.c (oom): Remove #ifdef SHARED/#endif.
        (_dl_static_dtv, _dl_initial_dtv): Moved before ...
        (_dl_allocate_tls_init): This.  Reallocate DTV if the current
        DTV isn't big enough.
        * nptl/Makefile (tests): Add tst-stack4.
        (modules-names): Add tst-stack4mod.
        ($(objpfx)tst-stack4): New.
        (tst-stack4mod.sos): Likewise.
        ($(objpfx)tst-stack4.out): Likewise.
        ($(tst-stack4mod.sos)): Likewise.
        (clean): Likewise.
        * nptl/tst-stack4.c: New file.
        * nptl/tst-stack4mod.c: Likewise.

-----------------------------------------------------------------------

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[david.abdurachmanov at gmail dot com]

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

--- Comment #18 from David Abdurachmanov <david.abdurachmanov at gmail dot com> ---
(In reply to H.J. Lu from comment #16)

> That is true. But it is a separate issue.

Is there a separate bug report for that, or one should be created?

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, hjl/pr13862 has been created
        at  b2d53cf4c7bc1fc7e5d92bfe783e8c03439c50bb (commit)

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b2d53cf4c7bc1fc7e5d92bfe783e8c03439c50bb

commit b2d53cf4c7bc1fc7e5d92bfe783e8c03439c50bb
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Thu Nov 27 05:42:23 2014 -0800

    Resize DTV if the current DTV isn't big enough

    This patch changes _dl_allocate_tls_init to resize DTV if the current DTV
    isn't big enough.  Tested on X86-64, x32 and ia32.

        [BZ #13862]
        * elf/dl-tls.c (oom): Remove #ifdef SHARED/#endif.
        (_dl_static_dtv, _dl_initial_dtv): Moved before ...
        (_dl_resize_dtv): This.  Extracted from _dl_update_slotinfo.
        (_dl_allocate_tls_init): Resize DTV if the current DTV isn't
        big enough.
        (_dl_update_slotinfo): Call _dl_resize_dtv to resize DTV.
        * nptl/Makefile (tests): Add tst-stack4.
        (modules-names): Add tst-stack4mod.
        ($(objpfx)tst-stack4): New.
        (tst-stack4mod.sos): Likewise.
        ($(objpfx)tst-stack4.out): Likewise.
        ($(tst-stack4mod.sos)): Likewise.
        (clean): Likewise.
        * nptl/tst-stack4.c: New file.
        * nptl/tst-stack4mod.c: Likewise.

-----------------------------------------------------------------------

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[hjl.tools at gmail dot com]

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

--- Comment #20 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to David Abdurachmanov from comment #18)
> (In reply to H.J. Lu from comment #16)
> 
> > That is true. But it is a separate issue.
> 
> Is there a separate bug report for that, or one should be created?

See PR 17090, PR 17620 and PR 17621.

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, hjl/pr13862 has been created
        at  f08bbe49c8820576e2149a5be44af0ce2ddb355b (commit)

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f08bbe49c8820576e2149a5be44af0ce2ddb355b

commit f08bbe49c8820576e2149a5be44af0ce2ddb355b
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Thu Nov 27 05:42:23 2014 -0800

    Resize DTV if the current DTV isn't big enough

    This patch changes _dl_allocate_tls_init to resize DTV if the current DTV
    isn't big enough.  Tested on X86-64, x32 and ia32.

        [BZ #13862]
        * elf/dl-tls.c: Include <atomic.h>.
        (oom): Remove #ifdef SHARED/#endif.
        (_dl_static_dtv, _dl_initial_dtv): Moved before ...
        (_dl_resize_dtv): This.  Extracted from _dl_update_slotinfo.
        (_dl_allocate_tls_init): Resize DTV if the current DTV isn't
        big enough.
        (_dl_update_slotinfo): Call _dl_resize_dtv to resize DTV.
        * nptl/Makefile (tests): Add tst-stack4.
        (modules-names): Add tst-stack4mod.
        ($(objpfx)tst-stack4): New.
        (tst-stack4mod.sos): Likewise.
        ($(objpfx)tst-stack4.out): Likewise.
        ($(tst-stack4mod.sos)): Likewise.
        (clean): Likewise.
        * nptl/tst-stack4.c: New file.
        * nptl/tst-stack4mod.c: Likewise.

-----------------------------------------------------------------------

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  d8dd00805b8f3a011735d7a407097fb1c408d867 (commit)
      from  167da422b30b35c9eb9fc819ce5d3b3b0d65c6f4 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=d8dd00805b8f3a011735d7a407097fb1c408d867

commit d8dd00805b8f3a011735d7a407097fb1c408d867
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri Nov 28 07:54:07 2014 -0800

    Resize DTV if the current DTV isn't big enough

    This patch changes _dl_allocate_tls_init to resize DTV if the current DTV
    isn't big enough.  Tested on X86-64, x32 and ia32.

        [BZ #13862]
        * elf/dl-tls.c: Include <atomic.h>.
        (oom): Remove #ifdef SHARED/#endif.
        (_dl_static_dtv, _dl_initial_dtv): Moved before ...
        (_dl_resize_dtv): This.  Extracted from _dl_update_slotinfo.
        (_dl_allocate_tls_init): Resize DTV if the current DTV isn't
        big enough.
        (_dl_update_slotinfo): Call _dl_resize_dtv to resize DTV.
        * nptl/Makefile (tests): Add tst-stack4.
        (modules-names): Add tst-stack4mod.
        ($(objpfx)tst-stack4): New.
        (tst-stack4mod.sos): Likewise.
        ($(objpfx)tst-stack4.out): Likewise.
        ($(tst-stack4mod.sos)): Likewise.
        (clean): Likewise.
        * nptl/tst-stack4.c: New file.
        * nptl/tst-stack4mod.c: Likewise.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                              |   20 ++++
 elf/dl-tls.c                           |  102 ++++++++++++--------
 nptl/Makefile                          |   17 +++-
 nptl/tst-stack4.c                      |  159 ++++++++++++++++++++++++++++++++
 elf/tst-pie2.c => nptl/tst-stack4mod.c |   24 ++----
 5 files changed, 262 insertions(+), 60 deletions(-)
 create mode 100644 nptl/tst-stack4.c
 copy elf/tst-pie2.c => nptl/tst-stack4mod.c (75%)

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

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV

[cvs-commit at gcc dot gnu.org]

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

--- Comment #23 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  0b3b57625388983a5545a21fe00569e92e988a8d (commit)
      from  d8dd00805b8f3a011735d7a407097fb1c408d867 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0b3b57625388983a5545a21fe00569e92e988a8d

commit 0b3b57625388983a5545a21fe00569e92e988a8d
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri Nov 28 07:59:50 2014 -0800

    Mention fix for PR 13862

-----------------------------------------------------------------------

Summary of changes:
 NEWS |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

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