[0/2] Work around GDB bug overwriting __libc_malloc

Message ID cover.1782766548.git.fweimer@redhat.com (mailing list archive)
Headers
Series Work around GDB bug overwriting __libc_malloc |

Message

Florian Weimer June 29, 2026, 9:06 p.m. UTC
  This is a workaround for a GDB bug where it overwrites __libc_malloc
(yes, the code) with user-supplied string literals during inferior
function call evaluation.

  [PATCH v3 0/2] gdb: Fix internal inferior calls through GNU IFUNCs
  <https://inbox.sourceware.org/gdb-patches/20260629153203.10142-1-muhammad.kamran@arm.com>

It works by recognizing on-stack and AT_ENTRY trampoline call sites in
the malloc IFUNC resolver.  If a call by GDB is detect, malloc is
invoked directly from the IFUNC resolver (returning a heap pointer),
instead of returning the __libc_malloc address.

An alternative approach would involve a flag in the TCB that is set and
cleared around the IFUNC resolver call.  It's perhaps cleaner, but it
adds a tiny overhead to every IFUNC resolution.

We could also special-case malloc and redirect its resolution without
the IFUNC mechanism.  However, I expect this requires that the
implementation that GDB sees through the symbol tables remains
sufficiently compatible with the one selected via the IFUNC-like
mechanism (unless GDB reads non-IFUNC symbol values from relocations,
too, which I doubt).

I fear we need something like this if we want to switch to IFUNCs for
malloc any time soon because we don't control the pace at which users
update their GDB version.

Thanks,
Florian

Florian Weimer (2):
  elf: Record original entry point in GLRO(dl_entry)
  aarch64: Add workaround for GDB bug handling string literals

 elf/rtld.c                                |  1 +
 sysdeps/aarch64/multiarch/malloc-ifuncs.c | 60 +++++++++++++++++------
 sysdeps/generic/ldsodefs.h                |  4 ++
 3 files changed, 51 insertions(+), 14 deletions(-)


base-commit: ccd4cd5324caaaea1bb12bc8cef073170da51a19
  

Comments

Andreas K. Huettel June 30, 2026, 1:57 p.m. UTC | #1
Am Dienstag, 30. Juni 2026, 06:06:46 Japanische Normalzeit schrieb Florian Weimer:
> This is a workaround for a GDB bug where it overwrites __libc_malloc
> (yes, the code) with user-supplied string literals during inferior
> function call evaluation.
> 
>   [PATCH v3 0/2] gdb: Fix internal inferior calls through GNU IFUNCs
>   <https://inbox.sourceware.org/gdb-patches/20260629153203.10142-1-muhammad.kamran@arm.com>
> 
> It works by recognizing on-stack and AT_ENTRY trampoline call sites in
> the malloc IFUNC resolver.  If a call by GDB is detect, malloc is
> invoked directly from the IFUNC resolver (returning a heap pointer),
> instead of returning the __libc_malloc address.

This is the kind of kludge one adds once and then never dares to remove...

In general it's much easier to update gdb than to update glibc. Do we really
need this?


> 
> An alternative approach would involve a flag in the TCB that is set and
> cleared around the IFUNC resolver call.  It's perhaps cleaner, but it
> adds a tiny overhead to every IFUNC resolution.
> 
> We could also special-case malloc and redirect its resolution without
> the IFUNC mechanism.  However, I expect this requires that the
> implementation that GDB sees through the symbol tables remains
> sufficiently compatible with the one selected via the IFUNC-like
> mechanism (unless GDB reads non-IFUNC symbol values from relocations,
> too, which I doubt).
> 
> I fear we need something like this if we want to switch to IFUNCs for
> malloc any time soon because we don't control the pace at which users
> update their GDB version.
> 
> Thanks,
> Florian
> 
> Florian Weimer (2):
>   elf: Record original entry point in GLRO(dl_entry)
>   aarch64: Add workaround for GDB bug handling string literals
> 
>  elf/rtld.c                                |  1 +
>  sysdeps/aarch64/multiarch/malloc-ifuncs.c | 60 +++++++++++++++++------
>  sysdeps/generic/ldsodefs.h                |  4 ++
>  3 files changed, 51 insertions(+), 14 deletions(-)
> 
> 
> base-commit: ccd4cd5324caaaea1bb12bc8cef073170da51a19
>