Re: dynlink.c: bug in reclaim_gaps leading to segfault in __libc_exit_fini

[Hugues Bruant <hugues@aerofs.com>]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

> > ==59== Invalid free() / delete / delete[] / realloc()
> > ==59==    at 0x4C92B0E: free (vg_replace_malloc.c:530)
> > ==59==    by 0x4056F68: reclaim_gaps (dynlink.c:488)
> > ==59==    by 0x405743D: map_library (dynlink.c:708)
> > ==59==    by 0x4057EF3: load_library (dynlink.c:1014)
> > ==59==    by 0x4058CA8: load_preload (dynlink.c:1112)
> > ==59==    by 0x4058CA8: __dls3 (dynlink.c:1581)
> > ==59==    by 0x405856A: __dls2 (dynlink.c:1383)
> > ==59==    by 0x405655E: ??? (in /lib/ld-musl-x86_64.so.1)
> > ==59==    by 0x3: ???
> > ==59==    by 0xFFF000E3A: ???
> > ==59==    by 0xFFF000E3E: ???
> > ==59==    by 0xFFF000E44: ???
> > ==59==    by 0xFFF000E86: ???
> >
> > Afterwards, the program proceeds with no issue, until it exists, at which
> > point a segfault is triggered when cleaning up shared libraries:
> >
>
> this is not a bug.

How confident of that are you?

Something is reliably overwriting 32 bytes of a dso struct. Valgrind
supposedly catches out-of-bounds writes to heap-allocated arrays so
unless I'm mistaken, the absence of any other errors until the segfault
suggests that there is no out-of-bounds write and the logical conclusion
is that an allocation overlaps with the corrupted dso struct.

The program is not using any threads so if I understand correctly it sohuld
not be negatively affected by the small default stack size. In any case, I
enabled -fstack-protector-all and -fstack-check and this did not reveal any
issue so at this point I'm ruling out stack overflow as the source of the
corruption.

Quite frankly I'm hoping that the root cause is in libdmg-hfsplus because
it would be much easier to fix than musl but the evidence does not point
in that direction.

Any suggestions for further investigation would be appreciated.

[-- Attachment #2: Type: text/html, Size: 2357 bytes --]