Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 12 Jan 2021 14:04:54 -0800
From: enh <>
Cc: Florian Weimer <>
Subject: Re: Future directions for *_r functions

On Tue, Jan 12, 2021 at 12:30 PM Keith Packard <> wrote:

> Florian Weimer <> writes:
> > * Store a pointer in TLS space that points to the global data object on
> >   the main thread, and further TLS data on other threads.  This is the
> >   approach that was used for _res.
> This seems like it would avoid use-after-free, but I can't see how you'd
> ever manage to free the storage -- if you can't free it when the thread
> exits, when can you ever prove that it can't be reached by the
> application?
> It sounds like there may be intractable issues with fixing this in a way
> that preserves existing ABI consequences.

yeah, that's an interesting failure mode i hadn't thought of. but not one
i've seen in practice on Android, and i've seen a lot of buggy apps in my
time :-)

Android up to and including the current release (a) keeps this stuff in the
mmap() region that includes the thread's stack and (b) doesn't reuse thread
stacks, so you'd probably blow up pretty quickly if you did make this
mistake. (which is another thing to worry about if we do start
reusing thread stacks, which might happen this year. even if it does,
though, that's only likely to happen for apps, meaning toybox or whatever
wouldn't be affected. [not that toybox uses threads, but ykwim.])

> --
> -keith

Content of type "text/html" skipped

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.