lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


We found 2 issues in Lua, but one of those seems to be already fixed in recent versions.

Do you know for sure that the other bug was identified and knowingly fixed?  If not, then it might still be there, possibly masked by some other unrelated change (sometimes these kinds of bugs can be finicky), in which case you might still want to report it just in case.

FWIW, I tested your test1.lua.txt input file with two ASan builds of Lua, one gcc 12.2 and another clang 17 both on Linux, but neither produce the heap buffer overflow; instead, they both produce this output:

lua: /home/dsicilia/.../lua-5.4.3/lib/lundump.c:185: void loadConstants(LoadState*, Proto*): Assertion `0' failed.
fish: Job 1, '../lua-5.…' terminated by signal SIGABRT (Abort) 

David

On Thu, Mar 16, 2023 at 10:39 AM Betka, Maik <maik.betka@iste.uni-stuttgart.de> wrote:
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
=================================================================
==8274==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000009a0 at pc 0x000000443a4d bp 0x7ffeea8efce0 sp 0x7ffeea8efcd0
WRITE of size 8 at 0x6020000009a0 thread T0
    #0 0x443a4c in loadFunction (/home/rocky/lua/lua+0x443a4c)
    #1 0x44320b in loadFunction (/home/rocky/lua/lua+0x44320b)
    #2 0x44320b in loadFunction (/home/rocky/lua/lua+0x44320b)
    #3 0x4440c2 in luaU_undump (/home/rocky/lua/lua+0x4440c2)
    #4 0x4173d2 in f_parser (/home/rocky/lua/lua+0x4173d2)
    #5 0x4175c9 in luaD_rawrunprotected (/home/rocky/lua/lua+0x4175c9)
    #6 0x41bda9 in luaD_pcall (/home/rocky/lua/lua+0x41bda9)
    #7 0x41c345 in luaD_protectedparser (/home/rocky/lua/lua+0x41c345)
    #8 0x410343 in lua_load (/home/rocky/lua/lua+0x410343)
    #9 0x4574a3 in luaL_loadbufferx (/home/rocky/lua/lua+0x4574a3)
    #10 0x468012 in luaB_load (/home/rocky/lua/lua+0x468012)
    #11 0x41a0ff in luaD_precall (/home/rocky/lua/lua+0x41a0ff)
    #12 0x448d6a in luaV_execute (/home/rocky/lua/lua+0x448d6a)
    #13 0x41aee6 in luaD_callnoyield (/home/rocky/lua/lua+0x41aee6)
    #14 0x4175c9 in luaD_rawrunprotected (/home/rocky/lua/lua+0x4175c9)
    #15 0x41bda9 in luaD_pcall (/home/rocky/lua/lua+0x41bda9)
    #16 0x40feb4 in lua_pcallk (/home/rocky/lua/lua+0x40feb4)
    #17 0x4068c6 in docall (/home/rocky/lua/lua+0x4068c6)
    #18 0x407cc6 in pmain (/home/rocky/lua/lua+0x407cc6)
    #19 0x41a0ff in luaD_precall (/home/rocky/lua/lua+0x41a0ff)
    #20 0x41aeaa in luaD_callnoyield (/home/rocky/lua/lua+0x41aeaa)
    #21 0x4175c9 in luaD_rawrunprotected (/home/rocky/lua/lua+0x4175c9)
    #22 0x41bda9 in luaD_pcall (/home/rocky/lua/lua+0x41bda9)
    #23 0x40feb4 in lua_pcallk (/home/rocky/lua/lua+0x40feb4)
    #24 0x405ab4 in main (/home/rocky/lua/lua+0x405ab4)
    #25 0x7f6b3e2a8eaf in __libc_start_call_main (/lib64/libc.so.6+0x3feaf)
    #26 0x7f6b3e2a8f5f in __libc_start_main_alias_1 (/lib64/libc.so.6+0x3ff5f)
    #27 0x406184 in _start (/home/rocky/lua/lua+0x406184)

0x6020000009a0 is located 0 bytes to the right of 16-byte region [0x602000000990,0x6020000009a0)
allocated by thread T0 here:
    #0 0x7f6b3e659d98 in __interceptor_realloc (/lib64/libasan.so.6+0xb4d98)
    #1 0x428621 in luaM_malloc_ (/home/rocky/lua/lua+0x428621)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/rocky/lua/lua+0x443a4c) in loadFunction
Shadow bytes around the buggy address:
  0x0c047fff80e0: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
  0x0c047fff80f0: fa fa fd fd fa fa 00 fa fa fa 00 00 fa fa 00 00
  0x0c047fff8100: fa fa 00 00 fa fa 00 00 fa fa 00 fa fa fa 00 00
  0x0c047fff8110: fa fa 00 fa fa fa 00 fa fa fa 02 fa fa fa 00 03
  0x0c047fff8120: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 fa
=>0x0c047fff8130: fa fa 00 00[fa]fa 00 00 fa fa 00 00 fa fa 00 fa
  0x0c047fff8140: fa fa 00 00 fa fa 00 00 fa fa 00 fa fa fa 00 fa
  0x0c047fff8150: fa fa 02 fa fa fa 06 fa fa fa 00 00 fa fa 00 00
  0x0c047fff8160: fa fa 00 00 fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8170: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8180: 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
  Shadow gap:              cc
==8274==ABORTING

Best regards,
Maik

-----Original Message-----
From: Roberto Ierusalimschy <roberto@inf.puc-rio.br>
Sent: 15 March 2023 21:11
To: Lua mailing list <lua-l@lists.lua.org>
Subject: Re: Found heap-buffer-overflow with grammar-based fuzzer

> > I am researcher in software testing from the University of Stuttgart, Germany. We are testing grammar-based fuzzers and have chosen Lua as one of our fuzz targets for our experiments. We found 2 issues in Lua, but one of those seems to be already fixed in recent versions. Thus, here is the remaining issue we found, which still results in a crash in the current Lua version.
>
> Thanks for the report.
>
> I've been unable to reproduce this bug. Did you use any special value
> for the variable ASAN_OPTIONS? What compiler/version are you using?

Could you do the following change to lundump.c and run the example again?

@@ -248,6 +248,7 @@ static void loadDebug (LoadState *S, Proto *f) {
     f->locvars[i].endpc = loadInt(S);
   }
   n = loadInt(S);
+printf("%d %d\n", n, f->sizeupvalues);
   for (i = 0; i < n; i++)
     f->upvalues[i].name = loadStringN(S, f);
 }

(The two printed numbers should be equal...)

Many thanks,

-- Roberto