On Sun, 24 Sep 2023 09:58:53 +0200, Otto Moerbeek wrote:

> The wayland issue was found as well, using the same method.
> I'm working on programming the heuristic that is quite effective into
> malloc itself. It currently looks like this for the X case above:
> X(67417) in malloc(): write to free mem 0xdd0277d4270 [0..7]@16
> allocated at /usr/lib/libc.so.97.1 0x92f22
> (preceding chunk 0xdd0277d4260 allocated at /usr/X11R6/bin/X 0x177374 (now fr
> ee))
> $ addr2line -e /usr/lib/libc.so.97.1 0x92f22
> /usr/src/lib/libc/string/strdup.c:45
> $ addr2line -e /usr/X11R6/bin/X 0x177374
> /usr/xenocara/xserver/Xext/xvdisp.c:995
> The idea is: if a buffer overflow is detected, it is very wel possible
> that the overwrite happened as an out-of-bound write of the preceding
> chunk. It is also possible that it is a genuine write-after-free, in
> that case the developer should inspect the code that allocated and
> manipulated the first chunk. Malloc has no way to the the difference,
> that requires debugging by a human.
> This is all experimental and the final form may change but it
> certainly look promising, especially as regular malloc code did not
> change at all (the extra info needed is only collected if malloc flag
> D is set).

This is very cool.  Being able to tell where the (now-freed) chunk
was allocated is a huge help in debugging this kind of issue.

 - todd

Reply via email to