current status about last bugs

[Roberto Ierusalimschy <roberto@...>]

This is what we figured out until now:

- Stack overflow in luaO_pushvfstring

Seems to be the issue pointed out by Andrew, of wrong computation of
nCcalls when entering a coroutine. (I did not check that yet.)


- Heap use after free in luaD_call

Macro 'checkstackp' can run a GC step and destroy the Call Info
previously allocated to call a function. (Andrew came to the same
conclusion.)

quick fix: call 'next_ci' only after checking the stack.


- Heap overflow in luaT_adjustvarargs

Bug caused by wrong order in macro checkstackGC; it should check the
GC before resizing the stack. (Also pointed out by Andrew.)

quick fix: change the order of operations in checkstackGC.


- heap-buffer-overflow in getobjname

Macro checkGC (in the luaV_execute) must save the 'pc', since a GC
step can raise errors. Even though the error is not propagated, it
still needs a valid pc to generate the error message. (Related, the
call to luaT_adjustvarargs must be protected, for a similar reason.)

quick fix: save pc in macro checkGC and protect the call to
luaT_adjustvarargs.


- heap-buffer-overflow in luaD_pretailcall

Didn't check yet, but it seems to be the caused by the
same problem with macro checkstackGC. (At least it goes away when
we fix that macro.)


- Heap overflow in luaH_get

Until now, I have no clues about this one. It seems to be a real problem
in the GC, but it is hard to reproduce. Applying the previous fixes
makes it desapear, but I cannot see how they could solve the bug.

-- Roberto