Bug 210779 - VSYSCALL page has invalid permissions
VSYSCALL page has invalid permissions
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Ernie Petrides
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-10-14 18:31 EDT by Jan Kratochvil
Modified: 2007-11-16 20:14 EST (History)
3 users (show)

See Also:
Fixed In Version: RHBA-2007-0304
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-07 23:49:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jan Kratochvil 2006-10-14 18:31:12 EDT
Description of problem:
/proc/*/maps constains VSYSCALL/vDSO page with invalid permissions.
It now needs a workaround in gdb(1) - as part of Bug 179399, reporting mostly as
it may affect also other programs.
It affects native x86_64, native i386 and also i386-on-x86_64 binaries.
Unaware of VSYSCALL/vDSO state on non-x86 platforms.

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

How reproducible:

Steps to Reproduce:
1. cat /proc/self/maps

Actual results:
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 

Expected results:
ffffffffff600000-ffffffffffe00000 r-xp 00000000 00:00 0 

Additional info:
It has been fixed in recent (last 2 months) FC6/RawHide kernels, I did not track
down the specific change.
The workaround in gdb(1) is just for core-dumping "gcore" of i386 binaries
running on x86_64 platform:
static void
amd64_linux_gcore_create_hook (CORE_ADDR vaddr, int *read, int *write,
                               int *exec)
  if (gdbarch_ptr_bit(current_gdbarch) == 32
      && (CORE_ADDR) 0xffffe000 == vaddr
      && *read == 0 && *write == 0 && *exec == 0)
    *read = 1;
Comment 1 Dave Anderson 2006-10-23 12:29:52 EDT
> It has been fixed in recent (last 2 months) FC6/RawHide kernels, I did not track
> down the specific change.

Hi Jan,
Can you point me to a specific Red Hat kernel where you see something
other than "---p" for the "maps" line for the gate virtual memory area?

I ask because I cannot find any Red Hat kernels that have a "gate_vma" which
have its "vm_flags" field set to anything other than zero -- which causes
what you're seeing.  Here's the relevant kernel function:

static int show_map(struct seq_file *m, void *v)
        struct vm_area_struct *map = v;
        struct file *file = map->vm_file;
        int flags = map->vm_flags;
        unsigned long ino = 0;
        dev_t dev = 0;
        int len;

        if (file) {
                struct inode *inode = map->vm_file->f_dentry->d_inode;
                dev = inode->i_sb->s_dev;
                ino = inode->i_ino;

        seq_printf(m, "%08lx-%08lx %c%c%c%c %08lx %02x:%02x %lu %n",
                        flags & VM_READ ? 'r' : '-',
                        flags & VM_WRITE ? 'w' : '-',
                        (flags & VM_EXEC
#ifdef __i386__
                                || (!nx_enabled && map->vm_mm &&
                                (map->vm_start < map->vm_mm->context.exec_limit))
                                ? 'x' : '-',
                        flags & VM_MAYSHARE ? 's' : 'p',
                        map->vm_pgoff << PAGE_SHIFT,
                        MAJOR(dev), MINOR(dev), ino, &len);

Comment 2 Ernie Petrides 2006-10-24 16:06:52 EDT
Assigning this to myself.
Comment 3 Jan Kratochvil 2006-10-26 10:26:34 EDT
FC6-GA: kernel-2.6.18-1.2798.fc6.x86_64
$ set +H
$ echo 'int main(void) { for (;;); }' >deadlock.c;gcc -o deadlock32 deadlock.c
-ggdb3 -Wall -m32;./deadlock32 &cat /proc/$!/maps|grep ^ffff
ffffe000-fffff000 r-xp ffffe000 00:00 0 
$ echo 'int main(void) { for (;;); }' >deadlock.c;gcc -o deadlock64 deadlock.c
-ggdb3 -Wall -m64;./deadlock64 &cat /proc/$!/maps|grep ^ffff
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0                  [vdso]

RHEL4U4: kernel-smp-2.6.9-42.0.3.EL.x86_64
$ set +H
$ echo 'int main(void) { for (;;); }' >deadlock.c;gcc -o deadlock32 deadlock.c
-ggdb3 -Wall -m32;./deadlock32 &cat /proc/$!/maps|grep ^ffff
ffffc000-ffffe000 rw-p ffffc000 00:00 0   # ignore this line...
ffffe000-fffff000 ---p 00000000 00:00 0 
$ echo 'int main(void) { for (;;); }' >deadlock.c;gcc -o deadlock64 deadlock.c
-ggdb3 -Wall -m64;./deadlock64 &cat /proc/$!/maps|grep ^ffff
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 

You can see there the (32-bit only) "r-xp" (FC6-GA) vs. "---p" (RHEL4.4)
difference for the range ffffe000-fffff000 where the code hangs during backtrace
of a process in system call.

It should be fixed to "r-xp" even for the 64-bit mode but I am not aware of any
application using it, gdb(1) does not need it for the backtraces of 64-bit
Comment 4 Ernie Petrides 2006-11-08 19:05:18 EST
The fix for 32-bit processes running on x86_64 has already been committed
to the RHEL4 U5 patch pool on 11-Oct-2006 (in kernel version 2.6.9-42.18.EL)
as part of Eric Sandeen's fix for bug 178981.
Comment 5 Ernie Petrides 2006-11-08 19:50:04 EST
On i386, both upstream 2.6.18 and Fedora FC-6 kernels do not show a
vm region from 0xffffe000 to 0xfffff000 in /proc/<pid>/maps, and RHEL4
shows an unaccessible region (---p) which is truly unaccessible, since
it is mapped for kernel read-only access.

Thus, on i386 (i.e., x86), I don't believe any changes are appropriate.

I'm marking this BZ as specific to x86_64, and I'll address the remaining
case (native 64-bit processes on x86_64) tomorrow.
Comment 6 Ernie Petrides 2006-11-09 20:21:02 EST
A patch to fix the native 64-bit case on x86_64 has been posted for
internal review on 9-Nov-2006.  I've also sent a fix upstream.
Comment 8 Jason Baron 2006-11-14 13:25:11 EST
committed in stream U5 build 42.25. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/
Comment 10 Jay Turner 2006-12-18 09:50:16 EST
QE ack for RHEL4.5.
Comment 13 Red Hat Bugzilla 2007-05-07 23:49:42 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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