[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210223171543.GA31685@brightrain.aerifal.cx>
Date: Tue, 23 Feb 2021 12:15:52 -0500
From: Rich Felker <dalias@...c.org>
To: libc-coord@...ts.openwall.com
Subject: Lifetime of object returned by readdir
As a consequence of Austin Group issue 696 (which still does not seem
to be resolved properly), readdir_r is unusable and readdir should be
required to be thread-safe. Moreover, it's already disallowed for the
implementation to use a common static buffer for the result of
readdir since operations on different streams cannot overwrite each
other's results:
The returned pointer, and pointers within the structure, might be
invalidated or the structure or the storage areas might be
overwritten by a subsequent call to readdir() on the same directory
stream. They shall not be affected by a call to readdir() on a
different directory stream. The returned pointer, and pointers
within the structure, might also be invalidated if the calling
thread is terminated.
This leaves "part of the storage associated with the DIR stream
object" as the only reasonable place for the dirent to live, and of
course that's the natural (for zerocopy) place for it to live anyway,
and where it does live in existing implementations (at least glibc and
musl).
However, as part of resolving an application UAF bug where the dirent
was used after closedir, I realized that the specification fails to
mention closedir of the directory stream as a condition that can end
the lifetime of the dirent object. This seems like an omission, and
like it does not admit any implementation without severe memory leaks
-- the last dirent returned for each stream would have to be preserved
indefinitely unless the thread that called readdir exited.
I'd like to push to have this fixed (adding closedir as a condition
that ends the lifetime) as part of making readdir thread-safe, but
before opening a new Austin Group issue or following up on the
existing one there I'd like to make sure we're on the same page.
Rich
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.
