Bug 116044

this page is only "valid" if it's advertised via AT_SYSINFO, which it
isn't...... userspace is only allowed to use it if AT_SYSINFO is
present, and only at the location AT_SYSINFO points to.

Although FC2test1 does not advertise it via AT_SYSINFO, the page is
there and can be read and executed.  So there is still an inconsistency.

$ gdb hello
(gdb) b main
(gdb) run
(gdb) info proc
(gdb) shell cat /proc/PID/maps
ffffe000-fffff000 ---p 00000000 00:00 0
(gdb) x/x 0xffffe000
0xffffe000:     0x464c457f
(gdb)
0xffffe004:     0x00010101
(gdb)
0xffffe008:     0x00000000
(gdb)
0xffffe00c:     0x00000000

which shows that the page is a usual ELF executable (at least at the
beginning).

I'd be surprised if you can execute there.
If it doesn't get advertised (as we don't) then userspace is not
allowed to make any assumptions about anything.

User space may rely on what /proc/PID/maps reports, both positive
(exists, can do) and negative (does not exist, cannot do), to the
extent that the hardware allows [x86 has restrictions on combinations
of X and R, etc.]  That is one of the essential purposes of
/proc/PID/maps.  So in the case of FC2test1, there should at least be
Read perission indicated:
ffffe000-fffff000 r--p 00000000 00:00 0
[or else there is a bug in allowing gdb to read it, even though the
process cannot.]

gdb uses ptrace, which is special in relationship to page permissions.
(it's a debugger after all)

Here is a test program which reads the first 4 bytes of the dynso
syscall page without SIGSEGV, and gets the same answer (the ELF MAGIC
number) as gdb.  So the page is readable, so /proc/PID/maps is wrong
when it reports "---p" instead of "r--p".

$ cat foo.S
        .globl _start
_start:
        nop
        movl 0xffffe000,%eax
        nop
        movl $1,%eax
        movl $0,%ebx
        int $0x80
$ gcc -o foo -nostdlib -nostartfiles foo.S
$ ./foo
$   ## no SIGSEGV from executing ==> 0xffffe000 is readable.
$ gdb foo
(gdb) b *(1+_start)
(gdb) run
Breakpoint 1, 0x08048075 in _start ()
(gdb) x/i $pc
0x8048075 <_start+1>:   mov    0xffffe000,%eax
(gdb) stepi
0x0804807a in _start ()
(gdb) p/x $eax
$1 = 0x464c457f   ## ELF MAGIC number
(gdb) shell cat /proc/PID/maps
ffffe000-fffff000 ---p 00000000 00:00 0
(gdb)

Experimentation reveals symbol __kernel_vsyscall and appropriate
instruction bytes at 0xffffe400; but trying to transfer control to
that address using either a CALL or a JMP gets a SIGSEGV.  So there is
no eXecute permission, and the actual permissions are in fact "r--p".

Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.

This situation still exists in FC3, kernel-2.6.11-1.14_FC3; Re-open with Version
"fc3".

When advertised to the process by the kernel (using AT_SYSINFO), then glibc
(possibly including ld-linux.so.2) consults [reads] the vDSO page to find
__kernel_vsyscall, __kernel_sigreturn, __kernel_rt_sigreturn.  Further, gdb
consults the unwind and traceback information stored in that same page.  There
can be no doubt that the page is, and is intended to be, Readable and
eXecutable.  Therefore a correct status indication must include 'r' and 'x'.

Roland, is this fixed with the vdso work you recently did in FC4 ?
If so, that'll get backported to FC3 when I rebase to 2.6.12 after its release.

The missing vma flags on the fixmap vdso come from upstream.
The exec-shield compatible vdso uses a normal vma whose flags match reality.

An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

Fixed in kernel-2.6.12-1.1398_FC4.  The output now looks like
-----
$ cat /proc/self/maps
004d5000-004ef000 r-xp 00000000 03:45 36574      /lib/ld-2.3.5.so
004ef000-004f0000 r-xp 00019000 03:45 36574      /lib/ld-2.3.5.so
004f0000-004f1000 rwxp 0001a000 03:45 36574      /lib/ld-2.3.5.so
00850000-00851000 r-xp 00850000 00:00 0
009ee000-00b12000 r-xp 00000000 03:45 32627      /lib/libc-2.3.5.so
   ...
-----
where the "r-xp" for 00850000-00851000 is the correct access permissions for
linux-gate.so.1.