Out of bounds write on Fedora in `lua_getinfo`

[ginnyTheCat]

Fedora defines LUA_IDSIZE as 512 instead of the default 60. While this is an unorthodox choice, Lua does explicitly state it as something you can configure.

Due to mlua-sys always assuming a hardcoded value of 60, however, when calling lua_getinfo it reserves a smaller lua_Debug than the library expects and a out of bounds write occurs.

I encountered this issue due to ASAN reporting memory corruption after a lua function returned an error and mlua tried to create a stacktrace.

I'm not sure what the best solution is, but probably reading the system luaconf.h when compiling mlua-sys could work. It does not seem like Lua exposes this value at runtime.

ASAN_OPTIONS=report_objects=1 RUSTFLAGS="-Zsanitizer=address" cargo +nightly run -Zbuild-std --target "$(rustc -vV | grep host | cut -d " " -f2)"

[package]
name = "tmp"
version = "0.1.0"
edition = "2024"

[dependencies]
mlua = { version = "0.11.4", features = ["lua51"] }

use mlua::Lua;

fn main() {
    let lua = Lua::new();
    let dummy = lua.create_function(|_, ()| Ok(())).unwrap();
    dummy.info();
}

results in

=================================================================
==38411==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7b51b8302308 at pc 0x562acaec084d bp 0x7ffc8b31a6c0 sp 0x7ffc8b319e78
WRITE of size 512 at 0x7b51b8302308 thread T0
    #0 0x562acaec084c in strncpy /rustc/llvm/src/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:631:5
    #1 0x7f51ba3be83c  (/lib64/liblua-5.1.so+0x783c) (BuildId: 954ec911b8c046eaed720bdda648862ba48d0a76)
    #2 0x7f51ba3bf46a in lua_getinfo (/lib64/liblua-5.1.so+0x846a) (BuildId: 954ec911b8c046eaed720bdda648862ba48d0a76)
    #3 0x562acaf2af47 in mlua::function::Function::info::h15623eea502285ef /home/ginnythecat/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/mlua-0.11.4/src/function.rs:359:23
    #4 0x562acaf095ed in tmp::main::hf19d0f1b27fce878 /tmp/tmp.R4KIAG8yzk/src/main.rs:6:11
    #5 0x562acaf097da in core::ops::function::FnOnce::call_once::h6f8810efde8e323d /home/ginnythecat/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5
    #6 0x562acaf0928d in std::sys::backtrace::__rust_begin_short_backtrace::h544cb51bd6fc1e5a /home/ginnythecat/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:158:18
    #7 0x562acaf091c3 in std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h548ab7dabe09fc34 /home/ginnythecat/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:206:18
    #8 0x562acafc1281 in core::ops::function::impls::_$LT$impl$u20$core..ops..function..FnOnce$LT$A$GT$$u20$for$u20$$RF$F$GT$::call_once::ha305175d55b4d969 /home/ginnythecat/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:287:21
    #9 0x562acb116277 in std::panicking::catch_unwind::do_call::h2627269f33ae1289 /home/ginnythecat/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:590:40
    #10 0x562acb13ebfa in __rust_try std.5a76f30ff966f37c-cgu.14
    #11 0x562acb115e7e in std::panicking::catch_unwind::hfa0c79dac82cb67e /home/ginnythecat/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:553:19
    #12 0x562acb1444fa in std::panic::catch_unwind::hc97c7ce5dabcc004 /home/ginnythecat/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:359:14
    #13 0x562acb0dc803 in std::rt::lang_start_internal::_$u7b$$u7b$closure$u7d$$u7d$::hd23c1101e4862fd2 /home/ginnythecat/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:175:24
    #14 0x562acb116408 in std::panicking::catch_unwind::do_call::h32ef57805ae60b28 /home/ginnythecat/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:590:40
    #15 0x562acb13ebfa in __rust_try std.5a76f30ff966f37c-cgu.14
    #16 0x562acb115be6 in std::panicking::catch_unwind::hbc39049fbe195051 /home/ginnythecat/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:553:19
    #17 0x562acb1444bd in std::panic::catch_unwind::h54c5f3d04863aaba /home/ginnythecat/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:359:14
    #18 0x562acb0dc572 in std::rt::lang_start_internal::h367f8880634618a7 /home/ginnythecat/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:171:5
    #19 0x562acaf0912f in std::rt::lang_start::hf294fdfa9478024a /home/ginnythecat/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:205:5
    #20 0x562acaf0974d in main (/tmp/tmp.R4KIAG8yzk/target/x86_64-unknown-linux-gnu/debug/tmp+0x28b74d) (BuildId: eb4dd568f5c799b47b339920946cf31a714aeaa3)
    #21 0x7f51ba0ae574 in __libc_start_call_main (/lib64/libc.so.6+0x3574) (BuildId: 48c4b9b1efb1df15da8e787f489128bf31893317)
    #22 0x7f51ba0ae627 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x3627) (BuildId: 48c4b9b1efb1df15da8e787f489128bf31893317)
    #23 0x562acae4bc24 in _start (/tmp/tmp.R4KIAG8yzk/target/x86_64-unknown-linux-gnu/debug/tmp+0x1cdc24) (BuildId: eb4dd568f5c799b47b339920946cf31a714aeaa3)

Address 0x7b51b8302308 is located in stack of thread T0 at offset 776 in frame
    #0 0x562acaf2aadf in mlua::function::Function::info::h15623eea502285ef /home/ginnythecat/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/mlua-0.11.4/src/function.rs:349

  This frame has 11 object(s):
    [32, 152) '_2.i'
    [192, 216) '_40' (line 376)
    [256, 280) '_39' (line 376)
    [320, 344) '_37' (line 374)
    [384, 408) '_36' (line 374)
    [448, 472) '_25' (line 365)
    [512, 536) '_24' (line 365)
    [576, 624) '_22'
    [656, 776) 'ar' (line 356)
    [816, 832) '_sg' (line 353) <== Memory access at offset 776 partially underflows this variable
    [848, 856) 'lua' (line 350) <== Memory access at offset 776 partially underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/lib64/liblua-5.1.so+0x783c) (BuildId: 954ec911b8c046eaed720bdda648862ba48d0a76)
Shadow bytes around the buggy address:
  0x7b51b8302080: f8 f8 f8 f2 f2 f2 f2 f2 f8 f8 f8 f2 f2 f2 f2 f2
  0x7b51b8302100: f8 f8 f8 f2 f2 f2 f2 f2 f8 f8 f8 f2 f2 f2 f2 f2
  0x7b51b8302180: f8 f8 f8 f2 f2 f2 f2 f2 f8 f8 f8 f2 f2 f2 f2 f2
  0x7b51b8302200: f8 f8 f8 f2 f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f2 f2
  0x7b51b8302280: f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x7b51b8302300: 00[f2]f2 f2 f2 f2 00 00 f2 f2 00 f3 f3 f3 f3 f3
  0x7b51b8302380: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3
  0x7b51b8302400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7b51b8302480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7b51b8302500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7b51b8302580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
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
==38411==ABORTING

[khvzak]

In the early days, mlua had a program to run a C preprocessor and dump Lua constants to a rust file to include it.
Unfortunately this approach was not flexible and in particular it did not work for cross compilation (resulted binary cannot be executed on host system).

I'm not sure what the best solution is, but probably reading the system luaconf.h when compiling mlua-sys could work.

I'm afraid it's quite unreliable approach. Usually a C preprocessor is required to do this properly. A constant can be wrapped in many #ifdef blocks and there is no guarantee that reading C file without running all directives will produce a right result.

I personally don't support the Fedora's approach to redefine LUA_IDSIZE to 512. Not only Rust programs are broken, but all C pre-compiled (binary) as well.
Also for majority of cases LUA_IDSIZE of 512 will not give any benefit.

[ginnyTheCat]

I'm afraid it's quite unreliable approach. Usually a C preprocessor is required to do this properly.

Yea, I didn't mean literally reading the file, but using something like bindgen (even though I don't think it's a great library, idk about a better option).

Not only Rust programs are broken, but all C pre-compiled (binary) as well.

Only if they were compiled on a different system, but like this it's impossible for Fedora themselves to package Rust binaries if they use mlua, since it doesn't rely on the Fedora header files.

A option could be I guess to read the header files during compilation and emitting a warning via Cargo when the config differs from the default one.