You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 985ec87
Browse filesBrowse the repository at this point in the historyBrowse files
vfs: do not reuse the path of a loaded memfd image
On Linux an addon or FFI library inside a VFS is loaded from an
anonymous memfd through /proc/self/fd/N, and the memfd was closed
right after a successful load. The next image then got the same fd
number, hence the same path, and the dynamic loader, which knows a
loaded object by the path it was opened with, returned the object
already loaded under that path instead of loading the new file. So
the second of any two addons or libraries loaded from a VFS resolved
to the first: an addon after an FFI library failed with "Module did
not self-register", an FFI library after an addon had none of its
own symbols, and two addons silently became the same one.
The fd is only needed until dlopen() returns, as the load's mapping
keeps the memory alive from then on; what must not be shared is the
path. Before the load, ask the loader with RTLD_NOLOAD whether the
path is already taken, and if so move the fd to a higher number with
F_DUPFD_CLOEXEC until it is free. Holding the fd from the check
through the load keeps anyone else from taking the path in between,
so this needs neither a counter nor a lock, and a library that has
really been unloaded gives its number back. The fd is closed right
after the load, whether or not it worked. Should no free number be
left, the image goes to a temp file.
The leak checks of test-vfs-addon and test-ffi-vfs compared the shared
temporary directory before and after the load, so off Linux any other
test loading from bytes at the same time could pass for a leak. Point
TMPDIR at a directory each test owns instead.
Signed-off-by: Philipp Dunkel <pip@pipobscure.com>
PR-URL: #67068
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
0 commit comments