| PUC Rio Lua | ||
|---|---|---|
| LuaJIT | ||
| Tarantool | 
is a set of fuzzing tests for C implementations of Lua runtime (PUC Rio Lua and LuaJIT).
git clone https://github.com/ligurio/lua-c-api-tests
cd lua-c-api-tests
git clone https://github.com/ligurio/lua-c-api-corpus
CC=clang CXX=clang++ cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug -DUSE_LUA=ON [-DUSE_LUAJIT=ON]
cmake --build build --parallelCMake options:
- USE_LUAenables building PUC Rio Lua.
- USE_LUAJITenables building LuaJIT.
- LUA_VERSIONcould be a Git branch, tag or commit. By default- LUA_VERSIONis- masterfor PUC Rio Lua and- v2.1for LuaJIT.
- ENABLE_LUAJIT_RANDOM_RAenables randomness in a register allocation. Option is LuaJIT-specific.
- ENABLE_ASANenables AddressSanitizer.
- ENABLE_UBSANenables UndefinedBehaviorSanitizer.
- ENABLE_COVenables coverage instrumentation.
- ENABLE_LUA_ASSERTenables all assertions inside Lua source code.
- ENABLE_LUA_APICHECKenables consistency checks on the C API.
- OSS_FUZZenables support of OSS Fuzz.
- ENABLE_BUILD_PROTOBUFenables building Protobuf library, otherwise system library is used.
- ENABLE_INTERNAL_TESTSenables internal tests.
- ENABLE_LAPI_TESTSenables Lua API tests.
cmake --build build --target test
cd build && RUNS=100000 ctest -R luaL_gsub_test --verbose
<snipped>
1: Done 100000 runs in 5 second(s)- Lua 5.4 Reference Manual: 4 – The Application Program Interface
- Lua 5.3 Reference Manual: 4 – The Application Program Interface
- Lua 5.2 Reference Manual: 4 – The Application Program Interface
- Lua 5.1 Reference Manual: 3 – The Application Program Interface
Fuzzing can find a wide variety of problems, but not all problems are considered bugs. Some problems are due to known limitations in the implementation. This section contains a list of such limitations in LuaJIT and PUC Rio Lua:
- In LuaJIT, the build infrastructure includes a source code that
contains memory leaks and other problems. For example,
src/host/buildvm.candsrc/host/minilua.c, these files are only used during the LuaJIT build process, and they are not a part of the LuaJIT itself. Memory leaks are suppressed in AddressSanitizer with a function__lsan_is_turned_off()that disallows leak checking for the program it is linked into.
- In LuaJIT, a function lj_str_new()may read past a buffer end (so-called "dirty" read), and that's ok. Suppressed in AddressSanitizer with__attribute__((no_sanitize_address)).
- In LuaJIT, bytecode input is unsafe; see LuaJIT#847
and LuaJIT FAQ. The string "mode" controls
whether the chunk can be text or binary (that is, a precompiled
chunk). It may be the string "b" (only binary chunks),
"t" (only text chunks), or "bt" (both binary and text). The
default is "bt". PUC Rio Lua and LuaJIT both have bytecode and
Lua source code parsers. It is desired to test both
parsers; however, the LuaJIT bytecode parser failed with the
assertion: LuaJIT ASSERT lj_bcread.c:123: bcread_byte: buffer read overflow, so with LuaJIT only text mode is used, and therefore only the text parser is tested.
- The debuglibrary is defined as unsafe. There are tons of ways to produce a crash with it. This library provides the functionality of the debug interface to Lua programs. Several of its functions violate basic assumptions about Lua code and therefore can compromise otherwise secure code. See LuaJIT#1264 and Lua 5.4 Reference Manual. Thedebugfunctions are not a subject of testing, and these functions are used carefully.
- In LuaJIT, there are a number of places with undefined behavior ("nonnull-attribute", "signed-integer-overflow", "bounds"). These problems remain unfixed and suppressed in UndefinedBehavior Sanitizer.
- In LuaJIT, there is a minimal C declaration parser, and it is not a validating C parser: "The parser ought to return correct results for properly formed C declarations, but it may accept some invalid declarations, too (and return nonsense)".
Copyright (C) 2022-2025 Sergey Bronnikov, released under the ISC license. See a full Copyright Notice in the LICENSE file.