Out-of-Bounds Read in luaL_loadstring Function Due to Lack of Input Validation

[Cullen Clay (你講話真的很機車)]

#### Vulnerability Description
The function `luaL_loadstring` in Lua's auxiliary library (`lauxlib.c`) is vulnerable to an out-of-bounds read (CWE-125) because it calls `strlen(s)` on the input parameter `s` without validating that `s` is a properly null-terminated string. If `s` is not null-terminated, `strlen(s)` will read beyond the bounds of the buffer in search of a null byte, leading to undefined behavior.

#### Tracing Data Flow
- **Source:** The input parameter `s` (of type `const char *`).
- **Sink:** The call to `strlen(s)`, which reads memory until a null terminator is found.
- **Path:** The flow from `s` to `strlen` is continuous and unsanitized, presenting a direct vulnerability when handling untrusted or malformed inputs.

#### Code Snippet
```c
// Method: luaL_loadstring#553#555#lauxlib.c
553: LUALIB_API int luaL_loadstring (lua_State *L, const char *s) {
554:   return luaL_loadbuffer(L, s, strlen(s), s);
555: }
```

#### Version Affected
The issue is present in version `0b73ed8f083c99b5ff88e0822532db7ad8785881`.

#### Conclusion
It is recommended to implement a validation check to ensure that the input parameter `s` is properly null-terminated before passing it to `strlen` to mitigate this vulnerability.

[Sainan]

Wow, this seems quite serious! Have you tried informing the maintainers of the 'strlen' function? I can imagine more than just Lua is affected by this vulnerability, which at this point may be considered a zeroday, even!

-- Sainan

[Berwyn Hoyt]

it calls `strlen(s)` on the input parameter `s` without validating that `s` is a properly null-terminated string.

Um ... I may be missing something obvious, but in C, how can you check that a char* points to a null-terminated string? To do so involves scanning it for a null terminator ... which is exactly what strlen does.

--
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 visit https://groups.google.com/d/msgid/lua-l/3ba203f0-0cb7-42ab-b82a-183123882bb6n%40googlegroups.com.

[bil til]

> To view this discussion visit https://groups.google.com/d/msgid/lua-l/CAKToXm9nOq3uymg49ybak%3DP5e5AyEKHQ-kSmQOM6oA1Ns8gPkA%40mail.gmail.com.

[Foster]

So a simple strlen would look like

size_t strlen (char *str) {
    size_t len = 0;
    while (*str != '\0') {
        str++;
        len++;
    }
    return len;
}

It's possible that the "user" put the characters "Lua Rocks" into the buffer, but did not put in the null end character.

So the full buffer of "Lua Rocks AI created CWE are the latest spam\0" would be used.  

So on the surface this may make sense. 

But this is one of a series of issues around doing load strings and loading Lua byte code.  

I know that I wake up and go "Hey, what random Lua byte code can I find and load it directly into my system via Lua".  

The Lua team is pretty good (30 years worth?) of making sure that the null characters are in the right place. 

The problem with these LLM bug reports is context.  They lack the ability to roll down the stack and look at the calling code to see "Ok, now slap a null \0 on the end" statements being used.  

I follow Daniel, the author of CURL, and his weekly tirades about AI generated CWE slop is pretty awesome.  

Roberto is too nice to call these AI_Clowns out.  I follow his lead and just hit the delete key after a small, sad sigh.  

[bil til]

Am Mi., 21. Jan. 2026 um 13:37 Uhr schrieb Berwyn Hoyt <ber...@gmail.com>:
>>

>> it calls `strlen(s)` on the input parameter `s` without validating that `s` is a properly null-terminated string.
> Um ... I may be missing something obvious, but in C, how can you check that a char* points to a null-terminated string?

you mean this ironic?

Typically for a string pointer it is quite common, that in a C
sourcecode at some crucial point you should include statements like
"assert(pc);" (or "assert( pc != NULL);" to be more explicit.

... but NOT everywhere of course.

Although it might be interesting if in luaconf.h might present a macro like:

#ifdef DETAILDEBUG
#define __assertifdetaildebug( x) assert(x)
#else
#fefine __assertifdetaildebug(x)
#endif

Then such extensive NULL pointer checking could be included into Lua
code without unnecessary "code bloating" in case of well written C
software... .

[Javier Guerra Giraldez]

i think it's now obvious that the responsible for this slop spam doesn't care enough to read any responses.  most probably this is a write-only email account.

i suggest simply blocking it.

in general, there might be well-intentioned people that do these things because they're just learning and think they might be useful.  for those cases, a good-natured response explaining why it's not a problem is the best answer.  but when it becomes obvious that there's nobody there, then nothing is lost by blocking.

--
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 visit https://groups.google.com/d/msgid/lua-l/CAOnDXmHq1RVXko28pjM1WCUkAsvW_%2B-kngvj1%3DcbJ-CjWZYrww%40mail.gmail.com.

--

Javier