lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Mike's take on it is correct; if an open upvalue points to ci->func
(which, AFAIK, is only possible via malicious bytecode) then it
becomes possible to cause the currently running function to be
collected. luaV_execute's LClosure *cl now points to unallocated (and
thus undefined) memory, causing anything which references it (i.e.
get/setglobal, get/setupvalue) to crash.

2008/10/20 Mike Pall <mikelu-0810@mike.de>:
> Roberto Ierusalimschy wrote:
>> > If a function's upvalues pointed to all the instances of that function
>> > on the stack, and assuming that the function does not exist in any
>> > tables, then if that function set all of it's upvalues to nil, and
>> > then a GC collection, then it would cause itself to be collected. This
>> > then causes all kinds of fun (i.e. segfaults) as the current
>> > environment table has probably just been collected as well.
>>
>> Could you explain better? I am afraid I cannot understand what you have
>> done.
>
> My take on it: the modified bytecode verifies ok, but crashes when
> run since the currently running function is collected. Normally
> this can't happen because there's always a reference to it at
> L->func = L->base-1. But the upvalue can be maliciously redirected
> to overwrite this stack slot.
>
> Summary: it's a bug in the bytecode verifier.
>
> --Mike
>