RE: PATCH: How to handle CallInfo func field safely?

[Tatsuhiro Aoshima <tatsuhiro.aoshima.md@...>]

Thanks you for your reply.

> That said, now that you mention it really is a bit strange that it does a straight cast with clLvalue, without any checking. I
wonder if it would make sense to have the `cl` be one of the parameters to luaV_execute. The places that call luaV_execute are all
places that have checked the type tag of the function object and have the `cl` at hand.

I think it is difficult to ensure that any call to luaV_execute satisfies that ci->func is actually TValue pointing to LClosure
object.
How do you ensure this as developments proceed?
Furthermore, if the stack is corrupted, OP_TAILCALL or OP_RETURN may read unexpected object in the stack into ci->func, which may
cause unexpected code execution.

My patch is very low overhead, and reduces any security risk due to this significantly.

。:+* ゜ ゜゜ *+:。:+* ゜ ゜゜ *+:。:+* ゜ ゜゜ *+:。
Tatsuhiro Aoshima
NTT Secure Platform Laboratories
Phone: +81 422 59 3261 [JPN: (0422) 59 3261]


-----Original Message-----
From: Hugo Musso Gualandi <hgualandi@inf.puc-rio.br> 
Sent: Wednesday, April 21, 2021 1:28 PM
To: Lua mailing list <lua-l@lists.lua.org>
Subject: Re: PATCH: How to handle CallInfo func field safely?



> I analyzed the use of CallInfo func field, then I figured out that the 
> field is used as either CClosure or LClosure.

There are actually 3 kinds of functions:
- Lua closures
- C closures
- Light C functions

The Lua calling convention is to push the function object to the Lua stack, followed by the function arguments. The `func` field
refers to this function object, which can be any of the 3 function types.

> First, at the entry of the VM dispatch loop (Lua 5.4.3), the CallInfo 
> func field is cast as LClosure as follows:

The VM dispatch loop only makes sense for Lua closures. It's only called in situations where it's known that it's a Lua closure.

That said, now that you mention it really is a bit strange that it does a straight cast with clLvalue, without any checking. I
wonder if it would make sense to have the `cl` be one of the parameters to luaV_execute. The places that call luaV_execute are all
places that have checked the type tag of the function object and have the `cl` at hand.

> Furthermore, the function index2value (./src/lapi.c) assumes that
> ci->func is type of either CClosure or LClosure implicitly as follows:

I think you might mean "light C function" instead of "Lua closure". The C API stuff is only accessible to C functions.

-- Hugo