Re: glibc 2.26 mtrace broken, missing allocations

[Carlos O'Donell <carlos at redhat dot com>]

On 04/05/2018 03:01 PM, Stefani Seibold wrote:
> Hi,
> 
> when using mtrace i get a report of a reallocation which has an address
> which was not reported.
> 
> For example:
> 
> @ /usr/lib64/libgobject-2.0.so.0:(g_signal_newv+0x23d)[0x7ffff7eb409d] - 0x5555559344c0
> @ /usr/lib64/libglib-2.0.so.0:(g_malloc+0x19)[0x7ffff7244039] + 0x555555922d40 0x60
> @ /usr/lib64/libglib-2.0.so.0:(g_realloc+0x20)[0x7ffff72440f0] < 0x5555558f0ea0
> @ /usr/lib64/libglib-2.0.so.0:(g_realloc+0x20)[0x7ffff72440f0] > 0x5555558f0ea0 0x10
> @ /usr/lib64/libglib-2.0.so.0:(g_realloc+0x20)[0x7ffff72440f0] < 0x5555558f0e70
> 
> The ingoing address 0x5555558f0ea0 for the realloc was not reported by
> an other alloc.

That's odd.

> The process (gvim -f) is single threaded and it is always the same
> address without address layout randomization.

OK, so as a single-threaded process it should be perfectly safe to use mtrace
(which is not MT-safe).

> How is this possible? Are there allocation functions which are not
> traced by mtrace?

I don't have any good answer for you.

The allocation functions all have hooks into the hook functions which are used
by mtrace. They are embedded into the libc.so.6 malloc API functions directly

e.g.

3026 void *
3027 __libc_malloc (size_t bytes)
3028 {
3029   mstate ar_ptr;
3030   void *victim;
3031 
3032   void *(*hook) (size_t, const void *)
3033     = atomic_forced_read (__malloc_hook);
3034   if (__builtin_expect (hook != NULL, 0))
3035     return (*hook)(bytes, RETURN_ADDRESS (0));

...

3136   void *(*hook) (void *, size_t, const void *) =
3137     atomic_forced_read (__realloc_hook);
3138   if (__builtin_expect (hook != NULL, 0))
3139     return (*hook)(oldmem, bytes, RETURN_ADDRESS (0));

And happen right away and record the result.

You should see *almost* all the results.

In theory the early dynamic loader bootstrap uses dl-minimal.c which has micro
allocator there for early bootstrap before libc.so.6's malloc can be called,
but none of those addresses should ever leak into the post-bootstrap for a realloc.
If such a thing did happen it would be a bug.

You can try running mcheck() and associated functions to enable additional checking.
Likewise mprobe().

DJ, You've been poking at this area, any thoughts?

-- 
Cheers,
Carlos.