[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: Found heap-buffer-overflow with grammar-based fuzzer
- From: "Betka, Maik" <maik.betka@...>
- Date: Thu, 16 Mar 2023 15:12:12 +0000
For the submitted bug (test1.lua.txt), I get the same message as David when I enable asserts with -DLUAI_ASSERT under "MYCFLAGS" in the makefile.
I have attached the other bug (test2.lua.txt).
Git commit: be908a7d4d8130264ad67c5789169769f824c5d1
Output:
=================================================================
==13==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x604000000f4c at pc 0x0000005259f5 bp 0x7ffc1b670600 sp 0x7ffc1b6705f8
READ of size 4 at 0x604000000f4c thread T0
#0 0x5259f4 in funcnamefromcode /home/rocky/lua/ldebug.c:597:19
#1 0x5259f4 in funcnamefromcall /home/rocky/lua/ldebug.c:649:12
#2 0x521bb8 in getfuncname /home/rocky/lua/ldebug.c:322:12
#3 0x521bb8 in auxgetinfo /home/rocky/lua/ldebug.c:357:24
#4 0x521bb8 in lua_getinfo /home/rocky/lua/ldebug.c:402:12
#5 0x59441a in luaL_argerror /home/rocky/lua/lauxlib.c:179:3
#6 0x5bb582 in luaB_next /home/rocky/lua/lbaselib.c:268:3
#7 0x53019d in luaD_precall /home/rocky/lua/ldo.c
#8 0x530dd0 in ccall /home/rocky/lua/ldo.c:639:13
#9 0x530dd0 in luaD_callnoyield /home/rocky/lua/ldo.c:659:3
#10 0x526f9b in luaG_errormsg /home/rocky/lua/ldebug.c:813:5
#11 0x52675e in luaG_runerror /home/rocky/lua/ldebug.c:832:3
#12 0x590db3 in luaV_execute /home/rocky/lua/lvm.c
#13 0x530e15 in ccall /home/rocky/lua/ldo.c:641:5
#14 0x530e15 in luaD_callnoyield /home/rocky/lua/ldo.c:659:3
#15 0x52b025 in luaD_rawrunprotected /home/rocky/lua/ldo.c:144:3
#16 0x5327b4 in luaD_pcall /home/rocky/lua/ldo.c:957:12
#17 0x51b142 in lua_pcallk /home/rocky/lua/lapi.c:1064:14
#18 0x5bc963 in luaB_xpcall /home/rocky/lua/lbaselib.c:494:12
#19 0x53019d in luaD_precall /home/rocky/lua/ldo.c
#20 0x586faa in luaV_execute /home/rocky/lua/lvm.c:1680:22
#21 0x530e15 in ccall /home/rocky/lua/ldo.c:641:5
#22 0x530e15 in luaD_callnoyield /home/rocky/lua/ldo.c:659:3
#23 0x52b025 in luaD_rawrunprotected /home/rocky/lua/ldo.c:144:3
#24 0x5327b4 in luaD_pcall /home/rocky/lua/ldo.c:957:12
#25 0x51b142 in lua_pcallk /home/rocky/lua/lapi.c:1064:14
#26 0x50beab in docall /home/rocky/lua/lua.c:160:12
#27 0x50beab in dochunk /home/rocky/lua/lua.c:196:34
#28 0x50beab in dofile /home/rocky/lua/lua.c:202:10
#29 0x50ac95 in pmain /home/rocky/lua/lua.c:654:10
#30 0x53019d in luaD_precall /home/rocky/lua/ldo.c
#31 0x530dd0 in ccall /home/rocky/lua/ldo.c:639:13
#32 0x530dd0 in luaD_callnoyield /home/rocky/lua/ldo.c:659:3
#33 0x52b025 in luaD_rawrunprotected /home/rocky/lua/ldo.c:144:3
#34 0x5327b4 in luaD_pcall /home/rocky/lua/ldo.c:957:12
#35 0x51b142 in lua_pcallk /home/rocky/lua/lapi.c:1064:14
#36 0x5093cd in main /home/rocky/lua/lua.c:671:12
#37 0x7f20987a5e4f in __libc_start_call_main (/lib64/libc.so.6+0x44e4f)
#38 0x7f20987a5efb in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x44efb)
#39 0x4246e4 in _start (/home/rocky/lua/lua+0x4246e4)
0x604000000f4c is located 4 bytes to the left of 44-byte region [0x604000000f50,0x604000000f7c)
allocated by thread T0 here:
#0 0x4cf42f in __interceptor_realloc (/home/rocky/lua/lua+0x4cf42f)
#1 0x54c6ec in luaM_realloc_ /home/rocky/lua/lmem.c:166:14
#2 0x54c6ec in luaM_saferealloc_ /home/rocky/lua/lmem.c:180:20
#3 0x54c6ec in luaM_shrinkvector_ /home/rocky/lua/lmem.c:116:14
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/rocky/lua/ldebug.c:597:19 in funcnamefromcode
Shadow bytes around the buggy address:
0x0c087fff8190: fa fa 00 00 00 00 03 fa fa fa 00 00 00 00 04 fa
0x0c087fff81a0: fa fa 00 00 00 00 02 fa fa fa 00 00 00 00 05 fa
0x0c087fff81b0: fa fa 00 00 00 00 01 fa fa fa 00 00 00 00 03 fa
0x0c087fff81c0: fa fa 00 00 00 00 02 fa fa fa 00 00 00 00 07 fa
0x0c087fff81d0: fa fa 00 00 00 00 00 04 fa fa 00 00 00 00 00 fa
=>0x0c087fff81e0: fa fa fd fd fd fd fd fd fa[fa]00 00 00 00 00 04
0x0c087fff81f0: fa fa 00 00 00 00 04 fa fa fa 00 00 00 00 00 00
0x0c087fff8200: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
0x0c087fff8210: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c087fff8220: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c087fff8230: 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
==13==ABORTING
Cheers,
Maik
-----Original Message-----
From: Roberto Ierusalimschy <roberto@inf.puc-rio.br>
Sent: 16 March 2023 16:04
To: Lua mailing list <lua-l@lists.lua.org>
Subject: Re: Found heap-buffer-overflow with grammar-based fuzzer
> Hello,
>
> at first, I couldn't reproduce the bug when I copied it from the email. So I guess there must be a particular byte-sequence present in the file to trigger it. When I used the original file (see attachment), however, it worked.
>
> gcc version 11.3.1 20220421 (Red Hat 11.3.1-2) (GCC)
>
> See the output of your requested code modification:
>
> $ cat ~/test1.lua | ./lua
> 0 0
> 1 1
> 1 1
> 1 1
> 0 0
> 1 1
> 180480 1
That seems to nail it. I was able to reproduce the bug now (with your
attachment and valgrind), and the overflow is exactly that problem
pointed out by Xmilia.
-- Roberto
c = xpcall (function (utf8, utf8, a, c, string, self) coroutine.resume(c, {[((0xc)%(0))]=(true)})
end, pairs ((true)))
