An heap-use-after-free is triggered in the insertkey()

[Sergey Bronnikov]

Hello,

an heap-use-after-free is triggered on execution of a Lua chunk below:

cat <<EOF >  chunk.lua
local lines = {}
local function hook()
  lines[#lines+0] = debug.getinfo(2).currentl8
end
debug.sethook(hook, "l", 0)
local function mm(_a, _b)
end
local mt = {}
for _ = 1, 100 do
  local parent = {}
  parent.__newindex = parent
  parent.bar = 0
  setmetatable(parent, grandparent)
  [3] = H child = setmetatable({},pgmatcharent)
  setmetatable(parent, grandparent)
  child = setmetatable({},parent)
  child.fo_nt = {}
  H = 2546325
  setmetatable(parent, grandparent)
  [1] = H
  lines = debug.getinfo(1),curre
end
EOF

How to reproduce:

make -j CC=clang MYCFLAGS="-Og -g -m32 -fsanitize=address -O0 -Wall -DLUAI_ASSERT -DLUA_USE_APICHECK" MYLDFLAGS="-fsanitize=address -m32"
./lua -e "loadfile('chunk.lua')()"

It is worth to say, the problem is not guaranteed to reproduce every time,
so it is better to execute in a for-loop:

for i in $(seq 1 1 150); do ./lua -e "loadfile('chunk.lua')()"; done

Reproduced on the latest version (53b41d0cddd80bf33fdc631bdd32e3ba53842b89)
that built with enabled macro -DLUAI_ASSERT.

==3997803==ERROR: AddressSanitizer: heap-use-after-free on address 0xe8215ac4 at pc 0x59b3b817 bp 0xffccee38 sp 0xffccee30
READ of size 1 at 0xe8215ac4 thread T0
    #0 0x59b3b816 in insertkey /src/testdir/build/lua-master/source/ltable.c:892:3
    #1 0x59b36330 in newcheckedkey /src/testdir/build/lua-master/source/ltable.c:906:16
    #2 0x59b36330 in reinserthash /src/testdir/build/lua-master/source/ltable.c:647:7
    #3 0x59b36330 in luaH_resize /src/testdir/build/lua-master/source/ltable.c:745:3
    #4 0x59b3e37d in rehash /src/testdir/build/lua-master/source/ltable.c:790:3
    #5 0x59b3e37d in luaH_newkey /src/testdir/build/lua-master/source/ltable.c:918:7
    #6 0x59b3d4d1 in luaH_finishset /src/testdir/build/lua-master/source/ltable.c:1179:5
    #7 0x59b50b4a in luaV_finishset /src/testdir/build/lua-master/source/lvm.c:345:9
    #8 0x59b65c25 in luaV_execute /src/testdir/build/lua-master/source/lvm.c:1390:11
    #9 0x59aee733 in ccall /src/testdir/build/lua-master/source/ldo.c:774:5
    #10 0x59aee733 in luaD_callnoyield /src/testdir/build/lua-master/source/ldo.c:792:3
    #11 0x59ad7200 in f_call /src/testdir/build/lua-master/source/lapi.c:1071:3
    #12 0x59ae73e8 in luaD_rawrunprotected /src/testdir/build/lua-master/source/ldo.c:166:3
    #13 0x59af082b in luaD_pcall /src/testdir/build/lua-master/source/ldo.c:1096:12
    #14 0x59ad6b84 in lua_pcallk /src/testdir/build/lua-master/source/lapi.c:1097:14
    #15 0x59ac5e4e in LLVMFuzzerTestOneInput /src/testdir/tests/capi/luaL_loadstring_test.c:43:2
    #16 0x59957ea7 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned int) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:619:13
    #17 0x59942fa2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned int) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:329:6
    #18 0x599489c5 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned int)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:865:9
    #19 0x59974217 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #20 0xeaba5cb8  (/lib/i386-linux-gnu/libc.so.6+0x24cb8) (BuildId: 0f6a23454651f08cb9b65ff6544d658177b59947)
    #21 0xeaba5d7b in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x24d7b) (BuildId: 0f6a23454651f08cb9b65ff6544d658177b59947)
    #22 0x5993c666 in _start (/home/sergeyb/sources/oss-fuzz/build/out/lua/luaL_loadstring_test+0x42666)

0xe8215ac4 is located 4 bytes inside of 28-byte region [0xe8215ac0,0xe8215adc)
freed by thread T0 here:
    #0 0x59a7d43a in free /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:51:3
    #1 0x59b7b1c1 in luaL_alloc /src/testdir/build/lua-master/source/lauxlib.c:1052:5
    #2 0x59b0e1ff in luaM_free_ /src/testdir/build/lua-master/source/lmem.c:153:3
    #3 0x59b375da in luaH_free /src/testdir/build/lua-master/source/ltable.c:824:3
    #4 0x59b03561 in freeobj /src/testdir/build/lua-master/source/lgc.c:856:7
    #5 0x59b0d972 in sweepgen /src/testdir/build/lua-master/source/lgc.c:1191:7
    #6 0x59b01c43 in youngcollection /src/testdir/build/lua-master/source/lgc.c:1354:3
    #7 0x59b01c43 in luaC_step /src/testdir/build/lua-master/source/lgc.c:1755:9
    #8 0x59acd521 in lua_pushstring /src/testdir/build/lua-master/source/lapi.c:581:3
    #9 0x59ba1f6d in settabss /src/testdir/build/lua-master/source/ldblib.c:113:3
    #10 0x59ba1f6d in db_getinfo /src/testdir/build/lua-master/source/ldblib.c:187:5
    #11 0x59aecacb in precallC /src/testdir/build/lua-master/source/ldo.c:663:7
    #12 0x59aedd4a in luaD_precall /src/testdir/build/lua-master/source/ldo.c
    #13 0x59b6074f in luaV_execute /src/testdir/build/lua-master/source/lvm.c:1729:22
    #14 0x59aee733 in ccall /src/testdir/build/lua-master/source/ldo.c:774:5
    #15 0x59aee733 in luaD_callnoyield /src/testdir/build/lua-master/source/ldo.c:792:3
    #16 0x59ad624e in lua_callk /src/testdir/build/lua-master/source/lapi.c:1053:5
    #17 0x59ba3438 in hookf /src/testdir/build/lua-master/source/ldblib.c:337:5
    #18 0x59ae9607 in luaD_hook /src/testdir/build/lua-master/source/ldo.c:468:5
    #19 0x59ae3ccb in luaG_traceexec /src/testdir/build/lua-master/source/ldebug.c:959:5
    #20 0x59b67fc9 in luaV_execute /src/testdir/build/lua-master/source/lvm.c:1309:9
    #21 0x59aee733 in ccall /src/testdir/build/lua-master/source/ldo.c:774:5
    #22 0x59aee733 in luaD_callnoyield /src/testdir/build/lua-master/source/ldo.c:792:3
    #23 0x59ad7200 in f_call /src/testdir/build/lua-master/source/lapi.c:1071:3
    #24 0x59ae73e8 in luaD_rawrunprotected /src/testdir/build/lua-master/source/ldo.c:166:3
    #25 0x59af082b in luaD_pcall /src/testdir/build/lua-master/source/ldo.c:1096:12
    #26 0x59ad6b84 in lua_pcallk /src/testdir/build/lua-master/source/lapi.c:1097:14
    #27 0x59ac5e4e in LLVMFuzzerTestOneInput /src/testdir/tests/capi/luaL_loadstring_test.c:43:2
    #28 0x59957ea7 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned int) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:619:13
    #29 0x59942fa2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned int) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:329:6
    #30 0x599489c5 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned int)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:865:9
    #31 0x59974217 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #32 0xeaba5cb8  (/lib/i386-linux-gnu/libc.so.6+0x24cb8) (BuildId: 0f6a23454651f08cb9b65ff6544d658177b59947)

previously allocated by thread T0 here:
    #0 0x59a7d992 in realloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:81:3
    #1 0x59b7b1b1 in luaL_alloc /src/testdir/build/lua-master/source/lauxlib.c:1056:12
    #2 0x59b0e785 in luaM_malloc_ /src/testdir/build/lua-master/source/lmem.c:206:22
    #3 0x59afd1d5 in luaC_newobjdt /src/testdir/build/lua-master/source/lgc.c:299:13
    #4 0x59afd1d5 in luaC_newobj /src/testdir/build/lua-master/source/lgc.c:313:10
    #5 0x59b37134 in luaH_new /src/testdir/build/lua-master/source/ltable.c:799:17
    #6 0x59b60558 in luaV_execute /src/testdir/build/lua-master/source/lvm.c:1421:13
    #7 0x59aee733 in ccall /src/testdir/build/lua-master/source/ldo.c:774:5
    #8 0x59aee733 in luaD_callnoyield /src/testdir/build/lua-master/source/ldo.c:792:3
    #9 0x59ad7200 in f_call /src/testdir/build/lua-master/source/lapi.c:1071:3
    #10 0x59ae73e8 in luaD_rawrunprotected /src/testdir/build/lua-master/source/ldo.c:166:3
    #11 0x59af082b in luaD_pcall /src/testdir/build/lua-master/source/ldo.c:1096:12
    #12 0x59ad6b84 in lua_pcallk /src/testdir/build/lua-master/source/lapi.c:1097:14
    #13 0x59ac5e4e in LLVMFuzzerTestOneInput /src/testdir/tests/capi/luaL_loadstring_test.c:43:2
    #14 0x59957ea7 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned int) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:619:13
    #15 0x59942fa2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned int) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:329:6
    #16 0x599489c5 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned int)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:865:9
    #17 0x59974217 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #18 0xeaba5cb8  (/lib/i386-linux-gnu/libc.so.6+0x24cb8) (BuildId: 0f6a23454651f08cb9b65ff6544d658177b59947)

SUMMARY: AddressSanitizer: heap-use-after-free /src/testdir/build/lua-master/source/ltable.c:892:3 in insertkey
Shadow bytes around the buggy address:
  0xe8215800: fd fd fa fa fd fd fd fa fa fa fd fd fd fd fa fa
  0xe8215880: fd fd fd fa fa fa fd fd fd fd fa fa fd fd fd fa
  0xe8215900: fa fa fd fd fd fd fa fa fd fd fd fa fa fa fd fd
  0xe8215980: fd fd fa fa fd fd fd fa fa fa fd fd fd fd fa fa
  0xe8215a00: fd fd fd fa fa fa fd fd fd fd fa fa fd fd fd fa
=>0xe8215a80: fa fa fd fd fd fd fa fa[fd]fd fd fd fa fa fd fd
  0xe8215b00: fd fa fa fa fd fd fd fd fa fa fd fd fd fa fa fa
  0xe8215b80: fd fd fd fd fa fa fd fd fd fa fa fa fd fd fd fd
  0xe8215c00: fa fa fd fd fd fa fa fa fd fd fd fd fa fa fd fd
  0xe8215c80: fd fa fa fa fd fd fd fd fa fa fa fa fa fa fa fa
  0xe8215d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==3997803==ABORTING

Sergey

[Martin Eden]

Hello Sergey,

I expect that using "debug" module voids warranty.

-- Martin

[Julien Cugnière]

Le jeu. 21 mai 2026 à 12:14, 'Martin Eden' via lua-l
<lu...@googlegroups.com> a écrit :

> On 2026-05-21 11:54, Sergey Bronnikov wrote:
> > Hello,
> >
> > an heap-use-after-free is triggered on execution of a Lua chunk below:
>

> 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?

Of course when using functions such as
debug.setlocal/setupvalue/setmetatable all bets are off. But in this
example, only debug.getinfo and debug.sethook are used. Theoretically
getinfo is a read-only operation (unless it needs to mutate some
internal state to gather the information?). Setting a hook can be
considered a modification of the state, but the hook itself is not
doing anything obviously dangerous. So it feels like such a use of the
debug library shouldn't be able to crash Lua?

[Martin Eden]

On 2026-05-21 13:23, Julien Cugnière wrote:
> This disclaimer is well known, but Sergey's example got me thinking:
> does it still apply to "read-only" uses of the debug library?
>
> Of course when using functions such as
> debug.setlocal/setupvalue/setmetatable all bets are off. But in this
> example, only debug.getinfo and debug.sethook are used. Theoretically
> getinfo is a read-only operation (unless it needs to mutate some
> internal state to gather the information?). Setting a hook can be
> considered a modification of the state, but the hook itself is not
> doing anything obviously dangerous. So it feels like such a use of the
> debug library shouldn't be able to crash Lua?

My point of view is that if manual states

"You should exert care when using this library. Several of its functions
[...] can compromise otherwise secure code."

then it's "no warranty" contract clause.

So even if single call of debug.getinfo() along with expected results
will encrypt my data and install rootkit -- no formal complains,
I was warned.

Also I consider posting murky computer-generated code in maillist as not
neat. I believe author is expected to do it's best to represent issue
in minimal essential form for human consumption.

-- Martin

[Sergey Bronnikov]

Hello, Julien,

You're right. I have exactly the same thoughts about the reproducer.

The debug functions here don't perform any destructive actions.

But this leads to the GC freeing the object we later access.

Sergey

[Roberto Ierusalimschy]

> > 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.

-- Roberto

[Roberto Ierusalimschy]

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

[Roberto Ierusalimschy]

> I've finally got some time to debug that, and it is a real bug!
>

> [...]

A distilled example:

local parent = {}
parent.__newindex = parent

collectgarbage()
local child = setmetatable({}, parent)
child.__newindex = {x = "hello"}
collectgarbage("step")
print(parent.__newindex.x)

-- Roberto

[Sergey Bronnikov]

Hello, Roberto,

On Friday, July 10, 2026 at 7:19:32 PM UTC+3 Roberto Ierusalimschy wrote:

<snipped>

 

I've finally got some time to debug that, and it is a real bug!

This is very cool!

 

<snipped> 

Sergey, was this bug found by OSS-Fuzz?

 

Yes, it's from there.

-- Roberto

[云风 Cloud Wu]

Roberto Ierusalimschy <rob...@inf.puc-rio.br>于2026年7月11日 周六00:19写道：

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

Interesting bug.

I guess we should call  luaC_barrierback() directly here instead of luaV_finishfastset(), and call  gcvalue(t) before luaV_fastset()