Support integration with luzer

[ligurio]

The patch enables using luzer for fuzzing Lua projects in OSS-Fuzz.

Usage:

sudo python infra/helper.py build_fuzzers lua-example
sudo python infra/helper.py check_build lua-example fuzz_basic
sudo python infra/helper.py run_fuzzer lua-example fuzz_basic

Closes #13782

[github-actions[bot]]

ligurio is integrating a new project:
- Main repo: https://github.com/ligurio/luzer
- Criticality score: 0.23250

[ligurio]

@jonathanmetzman could you please review?

[jonathanmetzman]

I can take a look at this but to be honest we're concerned about the maintenance burden supporting Lua will impose and somewhat doubtful of the impact. Could you maybe help us with the latter? Is the electrical grid, or something else very important running on Lua?

[ligurio]

I can take a look at this but to be honest we're concerned about the maintenance burden supporting Lua will impose and somewhat doubtful of the impact.

Yeah, I remember this concern and took it into account when developing the patch. Hence, I avoid introducing the support for yet another language toolchain. Instead, my patch adds a wrapper generator for Lua tests and modifies the code to run these wrappers. The runtime itself will be compiled by the project. The patch with implementation is about 70 LOC, other changes is an example and documentation. I also want to say that I want to make this contribution on my own behalf, not on behalf of any company, so I'll be here; I won't run away immediately after the merge :)

Could you maybe help us with the latter?

There are two main scenarios for using Lua:

• First one is projects, where Lua is used as a standalone programming language. In this scenario, of course, you'd also want to test applications using fuzzing, but I agree with you, the impact is doubtful. Moreover, there are not so much projects written in Lua (but they exist: Kong API Gateway ^18, Prosody IM ^19, etc.).
• The second one scenario is projects, where Lua is embedded into C/C++ applications with C extensions, and I'm most concerned about this one, because there's a high risk of presence of the issues specific for C/C++. Testing Lua's API with LibFuzzer/AFL isn't very practical, so I suggest integrating a specialized fuzzing engine for Lua API. Like you did with Atheris, that supports fuzzing of native extensions written for CPython.

Is the electrical grid, or something else very important running on Lua?

Physicists at CERN use LuaJIT (the Just-In-Time compiler) for computing physics accelerator beams ^1.

Network infrastructure (applications and known Lua-related CVE's):

• Cloudflare uses Lua for programming LuaJIT-based WAF, latest outage was happen due to untested the second branch in a Lua condition ^3
• PowerDNS, CVE-2019-3806 ^5
• OpenResty (web platform based on NGINX and LuaJIT): CVE-2024-33452, CVE-2024-39702, CVE-2024-25178, CVE-2020-36309, CVE-2020-11724, CVE-2022-24834
• Redis: CVE-2025-49844 (RCE) ^7, CVE-2025-46817 (RCE), CVE-2025-46818 (privilege escalation)
• HAProxy (HAProxy is used by a number of high-profile websites including GoDaddy, GitHub, Bitbucket, Stack Overflow, Reddit, Slack, Speedtest.net, Tumblr, Twitter and Tuenti and is used in the OpsWorks product from Amazon Web Services.)
• VoIP: FreeSWITCH and Asterisk ^17
• Snort (IDS/IPS): CVE-2013-4863 / CVE-2016-6255, CVE-2024-20359, CVE-2023-20198
• Suricata (IDS/IPS): CVE-2025-64344 ^8
• Cisco (Cisco IOS SSL VPN ^11): CVE-2025-41688
• NetBSD embedded Lua into the kernel (lua.4 ^9, Scriptable Operating Systems with Lua ^10)

Industrial cases:

• Volvo (Volvo cars like the V40 Cross Country embed Lua in their combined instrument panel)
• Fairino Robots ^15, ^16
• Automation using NodeMCU (This open-source hardware platform allows users to run Lua directly on the ESP8266 Wi-Fi chip.)
• Schneider Electric (SpaceLogic Room Controllers) ^12, ^13
• Samsung SmartThings ^14