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

[Rich Felker <dalias@libc.org>]

On Tue, Feb 16, 2016 at 07:05:27PM -0500, Hugues Bruant wrote:
> > > ==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.

Szabolcs Nagy has been trying to reproduce your crash but it doesn't
seem possible without valid input data for it to process. Could you
provide data that can be used to reproduce the crash?

Rich