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

Ulrich Weigand
2008-08-13T13:30:00Z

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