Ted Cooper <eximX0902w <at> linuxwan.net> writes: > On 11/12/10 06:31, Stefan Fritsch wrote: > > I was worried about constructs like this > > > > old_pool = store_pool; > > store_pool = SEARCH_POOL; > > reset_point = store_get(0); > > ... > > internal_search_find(...); > > ... > > store_reset(reset_point); > > store_pool = old_pool; > > > > In this case, the store_reset would reset MAIN_POOL, which is not what > > the caller of internal_search_find wanted to do. But after reading the > > store code some more, I think that store_reset() would cause exim to > > exit in this case, so it could only cause a DoS.
This should have read internal_*l*search_find, of course. > > > > But you may want to fix internal_lsearch_find() anyway, in order to > > prevent future bugs and to make it clearer in the code that there > > really is no problem. > > Is this what the pool_reset_issue patch in debian is about or is this an > even more significant change? No, that patch is for this issue. At the time I did the release, I was not yet convinced that this bug could not be triggered. > From what I can see it looks like a > sensible thing to do. It doesn't have a detrimental effect and puts the > global state back to the way it found it. > > Also, has the FD leak been addressed in an exim bug report at all? It > seems like a very sane thing to do also. There's no need for those to be > open to a running program. Maybe all relevant FDs should be marked with FD_CLOEXEC? Cheers, Stefan PS: Please CC me, I am not subscribed to this list. -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
