Re: Bug: long strings with REALLY long delimiters…

[Daurnimator <quae@...>]

On Wed, 12 Dec 2018 at 13:55, nobody <nobody+lua-list@afra-berlin.de> wrote:
>
> …like [===…===[a]===…===] cause all sorts of weird behavior (incl.
> crashes) in 5.3.x / 5.4 (git HEAD).  Try
>
> local eqs = ("="):rep(0x3ffffffe)
> local code = "return ["..eqs.."[a]"..eqs.."]"
> print(#assert(load(code))())
>
> It might segfault, it might print a huge number instead of 1 (or, minus
> the '#', print 'a]===…===]<<garbage>>' instead of a single 'a').
>
> And with ASAN (-fsanitize=address) you get told more gory details, like
> that it's trying to do a 0x1_0000_0001-long read (4GiB plus 1 Byte… that
> read size is stable over the next couple extra ='s).
>
> I haven't deeply looked into this, from a cursory glance it might be
> (partly?) caused by the separator length being tracked in an `int`,
> which affects (in 5.4/git)
>
> llex.c:251: skip_sep (return, locvar on next line)
> llex.c:264: read_long_string (funarg)
> llex.c:447: llex (locvar)
>
> A quick test (int --> ptrdiff_t in those 4 places) _seems_ to fix it,
> but there might be more…
>
> -- Marco

I have had this sitting in my drafts for over a year, I think this is
the same bug?:

The overflow is in https://www.lua.org/source/5.3/llex.c.html#skip_sep
Generate test file:

local f = assert(io.open("bug.lua", "w"))
local step = 1<<20
assert(f:write("--["))
local eq = string.rep("=", step)
for i=1, 2<<31, step do
    assert(f:write(eq))
end
assert(f:write("["))
f:close()