[PATCH] malloc tcache: Debugger now sees the address of the corrupted chunk.

[Adder]

On Sat, Dec 12, 2020 at 12:51 AM DJ Delorie <dj@redhat.com> wrote:
>
> Adder <adder.thief@gmail.com> writes:
> > But at that point, only the "next" field is available to the debugger
> > (it has been copied in tcache->entries[tc_idx] and is being dereferenced).
> > In particular, the address of the corrupted chunk is not available.
>
> Er, the address of the corrupted chunk is the 'e' value that we're
> returning from that function.  Why can't the debugger see that?

Because the crash occurs on the second (not the first) malloc after corruption.

Example: The crash occurs on the malloc for p9 (not the one for p7):

  free (p1);
  ...

  strcpy (p1, "Wonder!");
  ...

  // We copy the corrupted pointer, ((tcache_entry *) p1)->next,
  // to our array, as tcache->entries [tc_idx].
  // Yes, we now return p1 as e, as pointed out in the question.
  // (And, the user saves it in p7, but I doubt that is part of the question.)
  p7 = malloc (64);
  ...

  // We only crash now, when dereferencing the copy of the corrupted pointer.
  p9 = malloc (64);

(The core file does not generally capture p7 or, equivalently, p1.
The malloc for p7 generally occurs in a nested function call.)

The proposal is to dereference the-corrupted-pointer earlier,
while we still have the-pointer-to-the-corrupted-pointer (as e),
not just the-copy-of-the-corrupted-pointer (as tcache->entries [tc_idx]).