hppa: avoid NULL dereference of sym_map in elf_machine_rela()

  On 31-Oct-14, at 6:38 PM, Aaro Koskinen wrote:

>> Rather, the right solution is probably to find (or add) some switch  
>> to GCC
>> that changes what it emits from being a call to abort to be something
>> different.  It's possible that abort is OK and we just need to  
>> define an
>> appropriately minimal abort in rtld.  But it needs to be looked into.
>
> The other quick workaround I could find is -fno-delete-null-pointer- 
> checks.
>
> "[...] other optimization passes in GCC use this flag to control  
> global
> dataflow analyses that eliminate useless checks for null pointers  
> [...]"

This suggests that GCC deletes a null check that is useful.

The attached patch implements a trap insn and __builtin_trap().  It  
generates
a conditional trap (SIGFPE).  Carlos has used another instruction that  
generates
an illegal instruction trap.

Dave
--
John David Anglin	dave.anglin@bell.net
  

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.  

So we might as well fix abort in rtld.  We already have __assert_fail in
elf/dl-minimal.c for similar issues with enabling assert in rtld.  We could
just add an abort there.  It would be ideal to avoid any actual abort calls
in our own source code sneaking into rtld, because it's far better if
they're _dl_fatal_printf so there's a message.  But I can't think of a
reasonable way to make compiler-generated abort calls link while preventing
explicit abort calls in the source from linking, so we can live without
that ideal.
  

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
  

> 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.

It's very straightforward to define it for any machine that lacks it.  I
haven't actually done a survey of existing GCC backends.  You might want to
do that and report bugs to individual backends.