Re: Potential use-after-free in Lua 5.2.4

[Roberto Ierusalimschy <roberto@...>]

> I believe I found an issue in Lua 5.2.4.  The repro is to run the following code under an adress sanitizer [1].
> 
> #define LONG_VAR_NAME "____x____1____x____2____x____3____x____4_"
> 
>   lua::State L;
>   lua_gc(L, LUA_GCSETPAUSE, 0);
>   luaL_loadstring(L, "function f() end " LONG_VAR_NAME);
> 
> What happens is that a long string is created in llex.c:494 but later on, in lparser.cc:576, when close_func() tries to anchor that long string, it doesn't update the seminfo.ts with the anchored string. It still points to the old value, which has been GC-ed. Later on, when upvalues are searched in lparser.cc:225, this is a use-after-free access.
> 
> I believe the fix is the following diff, but I'd like an expert confirmation (I just dug into the Lua source code for two days, so I don't understand all its details).
> 
> --- a/lua/v5_2/src/lparser.c
> +++ b/lua/v5_2/src/lparser.c
> @@ -62,7 +62,7 @@ static void anchor_token (LexState *ls) 
>    lua_assert(ls->fs != NULL || ls->t.token == TK_EOS);
>    if (ls->t.token == TK_NAME || ls->t.token == TK_STRING) {
>      TString *ts = ls->t.seminfo.ts;
> -    luaX_newstring(ls, getstr(ts), ts->tsv.len);
> +    ls->t.seminfo.ts = luaX_newstring(ls, getstr(ts), ts->tsv.len);
>    }
>  }

I tested neither your code nor your analysis, but its seems plausible.
Lua 5.2.2 had a somewhat similar bug (anchoring one long string and
using another): https://www.lua.org/bugs.html#5.2.2-6

-- Roberto