[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Null dereference in findvararg via checkclosemth
- From: Mouse <mouse@...>
- Date: Thu, 29 Jun 2023 10:03:49 -0400 (EDT)
> static void checkclosemth (lua_State *L, StkId level) {
> const TValue *tm = luaT_gettmbyobj(L, s2v(level), TM_CLOSE);
> if (ttisnil(tm)) { /* no metamethod? */
> int idx = cast_int(level - L->ci->func.p); /* variable index */
> const char *vname = luaG_findlocal(L, L->ci, idx, NULL);
> const char *luaG_findlocal (lua_State *L, CallInfo *ci, int n, StkId *pos) {
> StkId base = ci->func.p + 1;
> const char *name = NULL;
> if (isLua(ci)) {
> if (n < 0) /* access to vararg values? */
> return findvararg(ci, n, pos);
> static const char *findvararg (CallInfo *ci, int n, StkId *pos) {
> if (clLvalue(s2v(ci->func.p))->p->is_vararg) {
> int nextra = ci->u.l.nextraargs;
> if (n >= -nextra) { /* 'n' is negative */
> *pos = ci->func.p - nextra - (n + 1);
I don't know the internal data structures enough to say anything
authoritative, but it strikes me as possible, at least, that the
assignment to *pos cannot be reached in this case because one of the
four ifs - two each in luaG_findlocal and findvararg - will always fail
when called this way from checkclosemth.
Is this a real issue? Have you managed to cause a crash with it?
If not, there might still be something worth fixing somewhere here,
even if only a comment in checkclosemth explaining why it's safe, but
I'd call it significantly less serious.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B