This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] hppa: avoid NULL dereference of sym_map in elf_machine_rela()
- From: Rich Felker <dalias at libc dot org>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: John David Anglin <dave dot anglin at bell dot net>, Aaro Koskinen <aaro dot koskinen at iki dot fi>, Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 1 Nov 2014 00:02:08 -0400
- Subject: Re: [PATCH] hppa: avoid NULL dereference of sym_map in elf_machine_rela()
- Authentication-results: sourceware.org; auth=none
- References: <1414791231-30990-1-git-send-email-aaro dot koskinen at iki dot fi> <20141031214255 dot 8FFB12C3ACC at topped-with-meat dot com> <20141031223801 dot GA17511 at drone dot musicnaut dot iki dot fi> <BLU436-SMTP91D615856A23994E55223E979A0 at phx dot gbl> <20141101023559 dot B667F2C3ACA at topped-with-meat dot com>
On Fri, Oct 31, 2014 at 07:35:59PM -0700, Roland McGrath wrote:
> Oh, yeah. abort is the generic fallback for __builtin_trap. Certainly
> just supporting __builtin_trap directly in a compiler backend (with no
> outcall) is best. But this issue might come up in other places or affect
> other machines, and the set of machines and compilers we support for
> building libc today most likely includes others that don't have a proper
> __builtin_trap.
While glibc has to work around it for the time being (either by not
using __builtin_trap, or by providing abort here), I think it would be
nice to press for fixing this on the compiler side. There's no good
reason for the compiler to generate a call to abort when every ISA
I've ever seen has HCF-type instructions that can be used directly
with no dependency on a function call. Aside from the ldso issues,
__builtin_trap or similar compiler-generated traps might be used in
places where the call is impossible, like handling a fatal condition
where the GOT is corrupt, where the TCB is corrupt (in which case
abort can't properly raise signals for the calling thread), or where
the function pointer used to make syscalls (via vdso on x86, for
instance) is corrupt. In the worst case, this corruption was caused by
an attacker who has happily put the address of shellcode at one of the
above places.
Rich