Bug 116044 - protections of dynso syscall page are reported incorrectly
protections of dynso syscall page are reported incorrectly
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-17 14:59 EST by John Reiser
Modified: 2015-01-04 17:04 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-15 19:34:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Reiser 2004-02-17 14:59:07 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1)
Gecko/20030225

Description of problem:
The page protections of the dynamic shared object syscall page
(typically 0xbfffe000) are reported as '---p' (no read, no write, no
execute, private) which says that the process cannot touch the page. 
However, in most cases the process does Read and eXecute that page to
perform "fast" syscalls as glibc chooses, so the protections should be
reported as 'r-xp' (read, no write, execute, private).


Version-Release number of selected component (if applicable):
kernel-2.6.2-1.81

How reproducible:
Always

Steps to Reproduce:
1. cat /proc/self/maps  |  tail -1
2.
3.
    

Actual Results:  ffffe000-fffff000 ---p 00000000 00:00 0


Expected Results:  ffffe000-fffff000 r-xp 00000000 00:00 0


Additional info:
Comment 1 Arjan van de Ven 2004-02-17 15:01:15 EST
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.
Comment 2 John Reiser 2004-02-17 15:09:32 EST
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).
Comment 3 Arjan van de Ven 2004-02-17 15:33:42 EST
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.
Comment 4 John Reiser 2004-02-17 15:48:03 EST
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.]
Comment 5 Arjan van de Ven 2004-02-17 15:49:43 EST
gdb uses ptrace, which is special in relationship to page permissions.
(it's a debugger after all)
Comment 6 John Reiser 2004-02-17 16:24:43 EST
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)


Comment 7 John Reiser 2004-02-17 17:40:44 EST
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".
Comment 8 Dave Jones 2005-04-16 01:15:12 EDT
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.
Comment 9 John Reiser 2005-04-16 17:43:52 EDT
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'.
Comment 10 Dave Jones 2005-04-16 17:47:47 EDT
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.
Comment 11 Roland McGrath 2005-04-16 22:57:59 EDT
The missing vma flags on the fixmap vdso come from upstream.
The exec-shield compatible vdso uses a normal vma whose flags match reality.

Comment 12 Dave Jones 2005-07-15 15:23:55 EDT
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.
Comment 13 John Reiser 2005-07-15 19:27:46 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.