On Sun, Oct 08, 2023 at 07:07:27PM +0200, Matthieu Herrb wrote:
> I can confirm that there's an issue here. However in my tests, I don't
> see a garbled error message.
> If I set MALLOC_OPTIONS=F then a double free is reported, which I
> tracked down to the realloc() calls in getNextLine() that will make
> the xf68_lex_val.str pointer point to already free()d memory.
> So the following patch, which invalidates this pointer before reading
> more data from the config file fixes the issue I'm seeing. Can you
> confirm that it also fixes it for you ?

Unfortunately it doesn't :-).

Or rather, yes and no...  Your patch does fix most cases, but I'm
still able to read free'd memory with a specially crafted config
file that contains bare 0x0d bytes as line separators instead of 0x0a.

For example, consider the following config file:

$ hexdump -C custom
00000000  23 66 6f 6f 0d 62 61 72  0a                       |#foo.bar.|

Running with your patch, (or unpatched), I see:

$ X -config custom

Parse error on line 1 of section InputClass in file custom
        "ßßßßßßßßon" is not a valid keyword in this section.

With my patch this 0x0d case was mitigated too.

If I set vm.malloc_conf=CFGJ, the behaviour becomes non-deterministic,
sometimes it segfaults, other times it just dumps what looks like 1024
0xdf bytes as the error string.

Reply via email to