Bug 210779 - VSYSCALL page has invalid permissions
VSYSCALL page has invalid permissions
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.4
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Ernie Petrides
Brian Brock
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2007-05-07 23:49:42 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 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):
kernel-smp-2.6.9-42.0.3.EL.i686
+
kernel-smp-2.6.9-42.0.3.EL.x86_64

How reproducible:
Always.

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",
                        map->vm_start,
                        map->vm_end,
                        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))
#endif
                        )
                                ? '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
processes.
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.

http://rhn.redhat.com/errata/RHBA-2007-0304.html

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