[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190215183836.GC23599@brightrain.aerifal.cx>
Date: Fri, 15 Feb 2019 13:38:36 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Bugs found while working on global thread list
1. __dl_thread_cleanup, used to free the thread-local dlerror buffer,
calls free from a context where the thread is no longer in a
consistent state, which is invalid now what free may be defined by the
application. The simplest fix seems to be queuing the buffer to a
global list where it will be seen and freed by some future call to dl
functions; this precludes unbounded (memory leak) growth.
2. dlsym for RTLD_NEXT or RTLD_DEFAULT walks the symbol-defining DSOs
list without holding any lock on it, and the full DSOs list for
addr2dso lookup. This is intentional in some sense, to avoid heavy
overhead, but it seems incorrect and unsafe, as it can cause a
definition which is only temporarily-global (as part of an in-progress
dlopen with RTLD_LOCAL) or not-yet-committed (as part of an
in-progress dlopen that eventually fails) to spuriously return success
for a symbol that should be seen as undefined. I think this may be
salvagable with some atomic sentinels, but it's probably better
(simpler, clearly correct without complex reasoning) to just use a
rwlock. (This issue was found looking at whether dlsym would be a
place to perform deferred free of buffers for #1 above.)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
