Re: [PATCH] fix atexit when it is called from an atexit handler

[Szabolcs Nagy <nsz@port70.net>]

* Jens Gustedt <jens.gustedt@inria.fr> [2015-07-24 08:52:23 +0200]:
> Am Freitag, den 24.07.2015, 02:16 +0200 schrieb Szabolcs Nagy:
> > 
> > $ printf '
> > set breakpoint pending on
> > break __cxa_atexit
> > commands
> > frame 0
> > continue
> > end
> > run
> > ' |gdb clang 2>/dev/null |grep '^Breakpoint' |wc -l
> > 610
> 
> interesting
> 
> > i.e. clang registers 610 atexit handlers.
> 
> hm, I don't think these are atexit handlers proper. I looked at the
> addresses (sort -u | less), most of them are different, so they are probably
> direct calls to __cxa_atexit, not to atexit.

they are destructors for static objects, but those are
atexit handlers too: they get into the same list.

(the c++ standard does not guarantee limits for static
objects with destructors even though it specifies the
limit for atexit handlers and requires interleaved
execution of atexit handlers and destructors, so the
only reasonable implementation is to use the same
mechanism for them.

in theory we could have a fixed array of 32 list items
for c atexit handlers and always malloc items for c++,
but that seems extra work just to provide the minimal
possible guarantees of the standards.)

> > i don't find atexit after exit dangerous: it is
> > a programmer error if there are a lot of atexit
> > calls,
> 
> that's what I meant
> 
> > not an input dependent dos attack surface.
> 
> I am not an expert in these, but AFAIR all function pointers that are
> stored in predictable places are attack surfaces.

if there is memory corruption and an attacker controls
the pointers then it is an attack surface, but without
memory corruption the number of atexit handlers
registered rarely depends on input at runtime, it's a
design decision by the programmer.