Skip to content
  • Kostya Kortchinsky's avatar
    [scudo] Fix improper TSD init after TLS destructors are called · 040c211b
    Kostya Kortchinsky authored
    Summary:
    Some of glibc's own thread local data is destroyed after a user's thread local
    destructors are called, via __libc_thread_freeres. This might involve calling
    free, as is the case for strerror_thread_freeres.
    If there is no prior heap operation in the thread, this free would end up
    initializing some thread specific data that would never be destroyed properly
    (as user's pthread destructors have already been called), while still being
    deallocated when the TLS goes away. As a result, a program could SEGV, usually
    in __sanitizer::AllocatorGlobalStats::Unregister, where one of the doubly linked
    list links would refer to a now unmapped memory area.
    
    To prevent this from happening, we will not do a full initialization from the
    deallocation path. This means that the fallback cache & quarantine will be used
    if no other heap operation has been called, and we effectively prevent the TSD
    being initialized and never destroyed. The TSD will be fully initialized for all
    other paths.
    
    In the event of a thread doing only frees and nothing else, a TSD would never
    be initialized for that thread, but this situation is unlikely and we can live
    with that.
    
    Reviewers: alekseyshl
    
    Reviewed By: alekseyshl
    
    Subscribers: llvm-commits
    
    Differential Revision: https://reviews.llvm.org/D37697
    
    llvm-svn: 312939
    040c211b
Loading