Skip to content

Race condition when custom .ctors entries call ip2unix symbols #29

Open
@aszlig

Description

@aszlig

This was reported via email and it happens whenever an application places entries via eg. __attribute__((constructor)) into the .ctors section. If the constructor then calls functions that we wrap, we might end up accessing uninitialised memory because at that time static data on our side might not be initialised.

The reporter also included a traceback:

#0  0x00007f1d834b56ed in std::__detail::_Mod_range_hashing::operator() (this=0x7f1d8371f740 <all_fds>, __num=3, __den=0) at /usr/include/c++/8/bits/hashtable_policy.h:434
#1  0x00007f1d834f36fe in std::__detail::_Hash_code_base<int, int, std::__detail::_Identity, std::hash<int>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, false>::_M_bucket_index (
    this=0x7f1d8371f740 <all_fds>, __c=3, __n=0) at /usr/include/c++/8/bits/hashtable_policy.h:1307
#2  0x00007f1d834f225c in std::_Hashtable<int, int, std::allocator<int>, std::__detail::_Identity, std::equal_to<int>, std::hash<int>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
+std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, true, true> >::_M_bucket_index (this=0x7f1d8371f740 <all_fds>, __k=@0x7ffc611d911c: 3, __c=3) at /usr/include/c++/8/bits/hashtable.h:638
#3  0x00007f1d834f092e in std::_Hashtable<int, int, std::allocator<int>, std::__detail::_Identity, std::equal_to<int>, std::hash<int>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
+std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, true, true> >::find (this=0x7f1d8371f740 <all_fds>, __k=@0x7ffc611d911c: 3) at /usr/include/c++/8/bits/hashtable.h:1435
#4  0x00007f1d834ef7bf in std::unordered_set<int, std::hash<int>, std::equal_to<int>, std::allocator<int> >::find (this=0x7f1d8371f740 <all_fds>, __x=@0x7ffc611d911c: 3) at /usr/include/c++/8/bits/unordered_set.h:650
#5  0x00007f1d834ee46c in Systemd::has_fd (fd=3) at ../src/systemd.cc:328
#6  0x00007f1d834bd504 in close (fd=3) at ../src/preload.cc:544
#7  0x00007f1d82dab0c9 in init_fips_mode () at crypto/o_init.c:36
#8  OPENSSL_init_library () at crypto/o_init.c:70
#9  0x00007f1d8372f8ba in call_init (l=<optimized out>, argc=argc@entry=3, argv=argv@entry=0x7ffc611d9598, env=env@entry=0x7ffc611d95b8) at dl-init.c:72
#10 0x00007f1d8372f9ba in call_init (env=0x7ffc611d95b8, argv=0x7ffc611d9598, argc=3, l=<optimized out>) at dl-init.c:30
#11 _dl_init (main_map=0x7f1d8394e1d0, argc=3, argv=0x7ffc611d9598, env=0x7ffc611d95b8) at dl-init.c:119
#12 0x00007f1d83720fda in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#13 0x0000000000000003 in ?? ()
#14 0x00007ffc611da602 in ?? ()
#15 0x00007ffc611da605 in ?? ()
#16 0x00007ffc611da608 in ?? ()
#17 0x0000000000000000 in ?? ()

So we should be able to trivially reproduce it with something like this:

void __attribute__ ((constructor)) foobar(void) {
    close(1);
}

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions