Re: Heap overflow in luaH_get

[云风 Cloud Wu <cloudwu@...>]

Andrew Gierth <andrew@tao11.riddles.org.uk> 于2020年7月9日周四 下午12:58写道：
>
> >>>>> "Yongheng" == Yongheng Chen <changochen1@gmail.com> writes:
>
>  Yongheng> READ of size 8 at 0x6060000020d8 thread T0
>  Yongheng>     #0 0x431a76 in luaH_get (/home/yongheng/lua_asan/lua+0x431a76)
>
> OK. I think I see some of what's going on with this one.
>
> The generational GC code seems to be assuming that a G_OLD1 object must
> be somewhere between g->survival and g->reallyold, or between g->finobj
> and g->finobjrold.
>
> But what happens in this case is that some table with an age of OLD1 has
> a metatable with a __gc metamethod, and when GCTM is being called for
> it, it gets moved back to the allgc list _at the front_, while remaining
> G_OLD1 (this is in udata2finalize).

I'm curious about that if the object moved back to the front of allgc
list and remaining G_OLD1, why this assert in sweepgen() haven't been
triggered ?

lua_assert(!isold(curr) && isdead(g, curr))
(https://github.com/lua/lua/blob/master/lgc.c#L1014)

I think  `psurvival = sweepgen(L, g, &g->allgc, g->survival);` in
youngcollection() may check whether the object is remaining G_OLD1 .