Re: Specially crafted binary chunks can cause Lua to crash

["Peter Cawley" <lua@...>]

Good point; I'd assumed that as numparams and maxstacksize were both
stored as bytes, that 256 would overflow them, but that's only when
storing in a byte again. It is odd that it is an assertion and not a
check though - it seems fairly important to check that parameters will
fit the stack.

In other news, precheck seems to assume that there is at least one
instruction in the function:

check(GET_OPCODE(pt->code[pt->sizecode-1]) == OP_RETURN);

Seems like a function with sizecode=0 will cause the above line to
access outside the array, so the following segfaults:

loadstring(string.dump(function()end):gsub("....\30%z\128%z.*",("\0"):rep(64),1))()

On 26/03/2008, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
> > On another note, the following exploits a bug in ldebug.c's precheck function:
>  >
>  > loadstring(string.dump(function(a,b,c)end):gsub("%z\3%z\3","\0\255\1\3",1))()
>  >
>  > The line in question is:
>  >
>  > lua_assert(pt->numparams+(pt->is_vararg & VARARG_HASARG) <= pt->maxstacksize);
>  >
>  > If numparams is 255, and is_vararg has the HARARG flag set, then the
>  > addition will overflow, and the function can have alot more parameters
>  > than stack slots, leading to a segfault when the function is called.
>
>
> Why would 255+1 overflow? What seems odd is the 'lua_assert' there. If
>  it is checking the code, it should use 'check'...
>
>
>  -- Roberto
>