Subject: Re: va 0 mapped - NULL pointer dereference succeeds
To: Simon Burge <firstname.lastname@example.org>
From: Charles M. Hannum <email@example.com>
Date: 10/25/2003 21:26:56
On Saturday 25 October 2003 12:32 pm, Simon Burge wrote:
> On Fri, Oct 24, 2003 at 05:40:43PM +0000, Charles M. Hannum wrote:
> > On Friday 24 October 2003 05:31 pm, Matthias Drochner wrote:
> > > Hi -
> > > on a pmax/-current, compiled with gcc3, I'm observing
> > >
> > > # pmap
> > > 00000000 52K read/exec /libexec/ld.elf_so
> > > 0000D000 252K [ anon ]
> > > 0004C000 8K read/write [ anon ]
> > > 00400000 208K read/exec /bin/csh
> > > [...]
> > >
> > > And indeed, a small (dynamically linked) test program can read
> > > from NULL, gets the contents of /libexec/ld.elf_so as expected.
> > >
> > > This shouldn't happen...
> > MIPS is still defining ELF_INTERP_NON_RELOCATABLE, a vestige from before
> > I made ld.elf_so relocatable on that platform. My guess is that a newer
> > version of binutils stopped linking it with the traditional VA offset
> > (0x5ffe0000), and so now it's mapping at 0.
> > Either the ld scripts should be fixed to use the old offset, or
> > ELF_INTERP_NON_RELOCATABLE should be removed, or both. It certainly
> > makes no sense as is.
> As Matthias mentioned, ld.elf_so is still linked at 0x5ffe0000 (for
> reasons I can't find - a long while ago I tried at VA offset 0 and
> everything still seemed to work fine).
It's due to changes in exec_elf32.c. The non-relocatable case is just plain