Re: An heap-use-after-free is triggered in the insertkey()
Roberto Ierusalimschy <[email protected]> Fri, 10 Jul 2026 13:19:25 -0300
| Newsgroups | gmane.comp.lang.lua.general |
|---|---|
| Message-ID | <[email protected]> |
> > > I expect that using "debug" module voids warranty.
> >
> > This disclaimer is well known, but Sergey's example got me thinking:
> > does it still apply to "read-only" uses of the debug library?
>
> Sure it does. For instance, by only reading the registry or a function
> upvalue we may be able to access (and then call) some function that
> otherwise could not be called at that point and (for instance) release some
> resource that is still being used.
>
> On the other hand, only because the example uses the debug library it does
> not imply that the real bug is a direct consequence of that use. As this
> bug involves the GC, it is worth investigating what is going on there.
I've finally got some time to debug that, and it is a real bug!
The core of the test case goes like this:
local parent = {}
parent.__newindex = parent
[...]
child = setmetatable({},parent)
child.fo_nt = {} --<< problem starts here
As 'child' doesn´t have that key, the metatable is invoked through
luaV_finishset. In the end of luaV_finishset, it needs to insert
the key into the __newindex table. In the example, that table is the
original table itself ('parent').
When it goes to insert key "fo_nt" into the 'parent' table, there is a
collision with "__newindex", and that previous entry (with the table
being updated) is moved to another place. Then, luaV_finishset proceeds
to check the barrier of the table (through 'luaV_finishfastset'), but
then the value 't' (which pointed to the "__newindex" entry) has already
another value, and so the barrier isn't called correctly, and so in the
next GC that new table (which now lives in parent.fo_nt) gets collected.
Sergey, was this bug found by OSS-Fuzz?
-- Roberto
--
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/lua-l/20260710161925.GA89477%40arraial.inf.puc-rio.br.