On Fri, 2010-12-10 at 09:26 +0100, Stefan Fritsch wrote: > I have found something else that looks fishy, but I don't know if it > can be triggered in practice: > > internal_lsearch_find() in src/lookups/lsearch.c sets store_pool to > MAIN_POOL but fails to reset store_pool to old_pool when returning > DEFER in line 199. Maybe this could lead to another function later > wrongly resetting the MAIN_POOL instead of the SEARCH_POOL which could > probbably result in memory corruption.
I think that's fine. It's only ever called from internal_search_find(), which is itself overriding store_pool to point to POOL_SEARCH before calling it, then setting it back again to whatever it was before. The only reason internal_lsearch_find() worries about old_pool is for its own purposes, because it wants to use some temporary space on POOL_MAIN and then switch back to SEARCH_POOL (or whatever pool its called had selected for it). -- dwmw2 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
