Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 24 Jul 2015 02:16:00 +0200
From: Szabolcs Nagy <>
Subject: Re: [PATCH] fix atexit when it is called from an atexit

* Jens Gustedt <> [2015-07-23 23:51:53 +0200]:
> Am Donnerstag, den 23.07.2015, 15:58 -0400 schrieb Rich Felker:
> > On Thu, Jul 23, 2015 at 09:19:13AM +0200, Jens Gustedt wrote:
> > > would be good if we could restrict the maximal number of successful
> > > calls to atexit during exit to 32. A calloc-free strategy could be to
> > > save head to a tmp a the beginning of processing and to provide a
> > > `struct fl` table on the stack of __funcs_on_exit.
> > 
> > I'm not sure how this would be better. It would be more predictable,
> > but could also probably break some excessive but "valid" use (like
> > a huge chain of ctors getting called from an atexit handler and all
> > registering dtors).
> I think this is really excessive and probably very poor design. atexit
> should not be abused to make an entry into the list on a per-object
> base.
> No application should expect to be able to submit more than 32
> handlers. After that atexit is allowed to fail, so everything more
> than that is not portable. I don't advocate to keep strictly on the 32
> bound (as we do for at_quick_exit), but once the process has entered
> the exit procedure, there should be pressure to get things terminated.

$ printf '
set breakpoint pending on
break __cxa_atexit
frame 0
' |gdb clang 2>/dev/null |grep '^Breakpoint' |wc -l

i.e. clang registers 610 atexit handlers.
(in case you wonder: gcc registers 2 including do_fini
of the musl runtime)

i don't find atexit after exit dangerous: it is
a programmer error if there are a lot of atexit
calls, not an input dependent dos attack surface.

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.