Re: [patch] nto target: fix null pointer dereference

["Ulrich Weigand" <uweigand@de.ibm.com>]

Aleksandar Ristovski wrote:
> Ulrich Weigand wrote:
> > Can you explain what the situation is that leads to a NULL
> > pointer here?
> 
> Your question made me go through the issue again.
> 
> To create inferior, we use spawnp. spawnp will do something like mmap
> the binary and that's pretty much it (DT_DEBUG in .dynamic will contain
> NULL pointer).
> 
> In procfs_create_inferior we call solib_create_inferior_hook, which will
> end up trying to determine loader base by reading inferior's memory at
> DT_DEBUG pointer. In our case, before the executable actually started
> executing, it will successfully read 0s, because dynamic loader has not
> been invoked yet, and the pointer to r_debug structure is not initialized.

I see.  However, so->lm_info->lm should still be always allocated by the
common solib-svr4.c routines (see svr4_current_sos):

      new->lm_info->l_addr = (CORE_ADDR)-1;
      new->lm_info->lm_addr = lm;
      new->lm_info->lm = xzalloc (lmo->link_map_size);

The only case where it is not allocated is in svr4_default_sos (which I
guess can happen in your case if the loader base is not found).

However, there the comment says:

      /* Nothing will ever check the cached copy of the link
         map if we set l_addr.  */
      new->lm_info->l_addr = debug_loader_offset;
      new->lm_info->lm_addr = 0;
      new->lm_info->lm = NULL;

Note the assumption that <lm> is only every used if <l_addr> is
not equal to -1.  This is also what the solib-svr4.c implementation
of LM_ADDR_CHECK does.

It seems the main problem is that NTO at some time copied some of
the logic from solib-svr4.c, but has not adapted to the changes that
were added to that file later on.  Not even the definition of struct
lm_info matches any more!

Maybe a more correct fix would be to mimic the new solib-svr4.c logic
and use the l_addr field to cache the load address?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com