Hi,
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.|
00000009
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.
