Segmentation fault in collectargs

[Bachir Bendrissou]

Hi,

Some Lua instruction is causing the interpreter to crash with a segmentation fault. The error is caused by a READ memory access.

I have reduced the crashing input to the following two instructions:

x = debug.getinfo(2)

x.func() 

Output:
Segmentation fault 

Exit code:
139

AddressSanitizer output:

AddressSanitizer:DEADLYSIGNAL

=================================================================

==5905==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0xaaaac78545e4 bp 0xffffded7ffe0 sp 0xffffded7ffe0 T0)

==5905==The signal is caused by a READ memory access.

==5905==Hint: address points to the zero page.

    #0 0xaaaac78545e4 in collectargs /home/lua-5.4.7/src/lua.c:288

    #1 0xaaaac78545e4 in pmain /home/lua-5.4.7/src/lua.c:629

    #2 0xaaaac7865bf4 in precallC /home/lua-5.4.7/src/ldo.c:529

    #3 0xaaaac7865bf4 in luaD_precall /home/lua-5.4.7/src/ldo.c:595

    #4 0xaaaac788e144 in luaV_execute /home/lua-5.4.7/src/lvm.c:1682

    #5 0xaaaac78667f8 in ccall /home/lua-5.4.7/src/ldo.c:637

    #6 0xaaaac78667f8 in luaD_callnoyield /home/lua-5.4.7/src/ldo.c:655

    #7 0xaaaac7863628 in luaD_rawrunprotected /home/lua-5.4.7/src/ldo.c:144

    #8 0xaaaac786755c in luaD_pcall /home/lua-5.4.7/src/ldo.c:957

    #9 0xaaaac785c7d4 in lua_pcallk /home/lua-5.4.7/src/lapi.c:1064

    #10 0xaaaac7853ea0 in docall /home/lua-5.4.7/src/lua.c:160

    #11 0xaaaac7854ed0 in handle_script /home/lua-5.4.7/src/lua.c:264

    #12 0xaaaac7854ed0 in pmain /home/lua-5.4.7/src/lua.c:653

    #13 0xaaaac7865bf4 in precallC /home/lua-5.4.7/src/ldo.c:529

    #14 0xaaaac7865bf4 in luaD_precall /home/lua-5.4.7/src/ldo.c:595

    #15 0xaaaac78667bc in ccall /home/lua-5.4.7/src/ldo.c:635

    #16 0xaaaac78667bc in luaD_callnoyield /home/lua-5.4.7/src/ldo.c:655

    #17 0xaaaac7863628 in luaD_rawrunprotected /home/lua-5.4.7/src/ldo.c:144

    #18 0xaaaac786755c in luaD_pcall /home/lua-5.4.7/src/ldo.c:957

    #19 0xaaaac785c7d4 in lua_pcallk /home/lua-5.4.7/src/lapi.c:1064

    #20 0xaaaac778b2b0 in main /home/lua-5.4.7/src/lua.c:681

    #21 0xffff946d73f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

    #22 0xffff946d74c8 in __libc_start_main_impl ../csu/libc-start.c:392

    #23 0xaaaac778b9ec in _start (/home/lua-5.4.7/src/lua+0x3b9ec)

AddressSanitizer can not provide additional info.

SUMMARY: AddressSanitizer: SEGV /home/lua-5.4.7/src/lua.c:288 in collectargs

==5905==ABORTING

The issue was replicated on the latest release Lua 5.4.6 and the latest development version Lua 5.4.7 (rc2).

Thank you,
Bachir Bendrissou

[Sainan]

This can easily be fixed by adding the following to lua.c's pmain:

luaL_checktype(L, 2, LUA_TLIGHTUSERDATA);  /* let's not deref any nullptrs if the user is being funny with the 'debug' library */

But I think doing stuff like that with the debug lib is generally a "waranty voided" situation, hence why it's not been fixed yet.

--
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 lua-l+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lua-l/6fe373a7-4677-416f-985e-f53c24f9131an%40googlegroups.com.

[Luiz Henrique de Figueiredo]

> I have reduced the crashing input to the following two instructions:
>
> x = debug.getinfo(2)
> x.func()

A Lua script should never be able to crash the host program.
Thanks for the report.

[Sainan]

I guess I should've reported this issue when I was made aware of it back in late 2023.

Although I just considered it to be non-solvable given that you an do a type-check for the lightuserdata to avoid a null-pointer dereference, but it would still be possible to give a 'valid' lightuserdata that was produced by C module (e.g. JSON modules commonly use a lightuserdata for a 'null' type).

> --
> 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 lua-l+un...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/lua-l/CAD55k3rLP_6Abfc9iY-d_wvAM0bO5A6WhGzhaqUVJGHY6KmegA%40mail.gmail.com.

[Roberto Ierusalimschy]

> I guess I should've reported this issue when I was made aware of it back in late 2023.
>
> Although I just considered it to be non-solvable given that you an do a type-check for the lightuserdata to avoid a null-pointer dereference, but it would still be possible to give a 'valid' lightuserdata that was produced by C module (e.g. JSON modules commonly use a lightuserdata for a 'null' type).

To properly avoid this behavior would require a new metatable just to type
this pointer, plus some other mechanism to ensure that the given 'argc'
is correct with respect to 'argv'. But to create that metatable before
calling 'pmain' could generate an unprotected 'not enough memory' error.

As said earlier, doing stuff like that with the debug lib is a "waranty
voided" situation, so it seems simpler to leave that as it is. There
are several other cases of similar nasty things that we can do with the
debug library. The manual is explicit about that.

-- Roberto

[Bachir Bendrissou]

Thank you all for your comments.

Luiz, was the bug fixed in the latest release, Lua 5.4.7 ?

[Luiz Henrique de Figueiredo]

> Luiz, was the bug fixed in the latest release, Lua 5.4.7 ?

[Alexander Walz]

Hello,

Lua 5.4.7 for OS/2 and DOS is out.

You will find the binary installers at

https://sourceforge.net/projects/agena/files/Lua%20for%20OS2%20and%20DOS/

along with the amended sources.

Yours,

Alex

[Sainan]

This is kind of hilarious. Would be funnier if those executables still worked on modern versions of Windows, but it seems 64-bit versions of Windows can't run 16-bit applications.