[Python-Dev] pymalloc killer

[Guido van Rossum]

> It's not obvious how it's vulnerable, so I'll spell it out:  Some thread
> that does hold the GIL and simultaneously calls a PyObject "get memory"
> routine ends up in the pymalloc malloc, and *if* that needs to allocate a
> new arena, and *if* that in turn requires growing the vector of arena base
> addresses, then there appears to be no way (short of slopping locks on
> everything) to guarantee that the *other* thread (in pymalloc free) won't
> pick up an address for the arena-base-address vector that's invalid by the
> time it gets around to indexing into it.  It's an extremely small hole (just
> a couple machine instructions), and requires an extremely unlikely set of
> circumstances to make it possible to fall into it, but it is a real hole all
> the same.

How about if the PyMem_Free guy saved the address of the vector before
using it, and checked that it was still the same afterwards, *and* if
the PyMem_Malloc guy didn't use realloc to resize the vector but
copied it to a newly malloc'ed vector, stored the new vector's
address, and then freed the old vector?

(I guess this is the same as what Martin suggested.  His point that
the global holding the vector address should be declared volatile is a
good one.)

--Guido van Rossum (home page: http://www.python.org/~guido/)