Bug 1389260

+++ This bug was initially created as a clone of Bug #1384344 +++

A race condition was found in the way Linux kernel's memory subsystem
handled breakage of the read only private mappings COW situation on
write access.

An unprivileged local user could use this flaw to gain
write access to otherwise read only memory mappings and thus increase
their privileges on the system.

Red Hat is aware of this issue and if you have questions about the affectedness of your system please contact Red Hat Support.  For additional information see https://access.redhat.com/security/vulnerabilities/2706661

--- Additional comment from Petr Matousek on 2016-10-19 12:16:23 EDT ---

Please note that this mitigation disables ptrace functionality which
debuggers and programs that inspect other processes (virus scanners)
use and thus these programs won't be operational.

Also this mitigation works against the In The Wild (ITW) exploit we are aware of but most likely does not mitigate the issue as a whole.

To mitigate the issue:


1) On the host, save the following in a file with the ".stp" extension:

probe kernel.function("mem_write").call ? {
        $count = 0
}

probe syscall.ptrace {  // includes compat ptrace as well
        $request = 0xfff
}

probe begin {
        printk(0, "CVE-2016-5195 mitigation loaded")
}


probe end {
        printk(0, "CVE-2016-5195 mitigation unloaded")
}


2) Install the "systemtap" package and any required dependencies. Refer
to the "2. Using SystemTap" chapter in the Red Hat Enterprise Linux
"SystemTap Beginners Guide" document, available from docs.redhat.com,
for information on installing the required -debuginfo and matching kernel-devel packages

3) Run the "stap -g [filename-from-step-1].stp" command as root.

If the host is rebooted, the changes will be lost and the script must be
run again.


Alternatively, build the systemtap script on a development system with
"stap -g -p 4 [filename-from-step-1].stp", distribute the resulting
kernel module to all affected systems, and run "staprun -L <module>" on those.
When using this approach only systemtap-runtime package is required on
the affected systems. Please notice that the kernel version must be the same
across all systems.

--- Additional comment from Petr Matousek on 2016-10-19 12:38:05 EDT ---

Acknowledgements:

Name: Phil Oester

--- Additional comment from Petr Matousek on 2016-10-19 12:45:36 EDT ---

[Edited 2016-10-26]
At the time of public disclosure, the in the wild exploit that we were aware of did not work on Red Hat Enterprise Linux 5 and 6 out of the box because on one side of the race it writes to /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise Linux 5 and 6.
Since public disclosure several Proof of Concepts (POC) have been published, that use ptrace method, which do work on Red Hat Enterprise Linux 5 & 6. 
It should be noted that the mitigation (System Tap Script listed in comment #13) has been effective in blocking all currently known POC that have been published.

--- Additional comment from Petr Matousek on 2016-10-19 14:06:00 EDT ---

Upstream patch:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619

--- Additional comment from Kurt Seifried on 2016-10-19 23:25:17 EDT ---


Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1387080]

--- Additional comment from Petr Matousek on 2016-10-20 04:28:15 EDT ---

Mitigation:

Please see bug 1384344 comment #13 (https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13) for details on how to mitigate this issue.

--- Additional comment from Drew Sears on 2016-10-20 17:09:09 EDT ---

(In reply to Petr Matousek from comment #16)
> The in the wild exploit we are aware of doesn't work on Red Hat Enterprise
> Linux 5 and 6 out of the box because on one side of the race it writes to
> /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise
> Linux 5 and 6.

But it does work on RHEL 7?

--- Additional comment from Joel Smith on 2016-10-20 18:45:32 EDT ---

While trying to install the systemtap mitigation, I got the following error until I installed the -debuginfo RPM for the kernels I was using.

> semantic error: while resolving probe point: identifier 'syscall' at
> /tmp/dirtycow.stp:5:7
>         source: probe syscall.ptrace {  // includes compat ptrace as well
>                       ^
> 
> semantic error: no match

I had to install

   kernel-devel-$(uname -r)
   systemtap
   kernel-debuginfo-$(uname -r)

before I could get stap to build the module for me. The instructions in comment #13 do mention the -debuginfo package, but I had confused -devel and -debuginfo and was getting that error until I had both.

--- Additional comment from Michael Carlson on 2016-10-20 22:04:29 EDT ---

(In reply to Drew Sears from comment #21)
> (In reply to Petr Matousek from comment #16)
> > The in the wild exploit we are aware of doesn't work on Red Hat Enterprise
> > Linux 5 and 6 out of the box because on one side of the race it writes to
> > /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise
> > Linux 5 and 6.
> 
> But it does work on RHEL 7?

I just tested this, and the exploit works on 7.

--- Additional comment from Ed Carp on 2016-10-21 12:52:46 EDT ---

I wasn't able to get this to work on RHEL 6.8 or 7.2:

[erc@lhqseltstut02 root]$ ls -l foo
-rw-r--r--. 1 root root 0 Oct 21 09:32 foo
[erc@lhqseltstut02 root]$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.2 (Maipo)
[erc@lhqseltstut02 root]$ ./dirtyc0w foo m00000000000000000
mmap ffffffff

madvise -100000000

procselfmem -100000000

[erc@lhqseltstut02 root]$ ls -l foo
-rw-r--r--. 1 root root 0 Oct 21 09:32 foo

Michael, how did you get it to work on RHEL7? What version are you running?

--- Additional comment from Ed Carp on 2016-10-21 13:42:50 EDT ---

Getting the same result on Fedora 22:

edwin.carp@7G32G72 ~$ ./dirtyc0w foo m00000000000000000
mmap ffffffff

madvise -100000000

procselfmem -100000000

edwin.carp@7G32G72 ~$ ls -l foo
-rw-r--r--. 1 root root 0 Oct 21 10:36 foo
edwin.carp@7G32G72 ~$ cat foo
edwin.carp@7G32G72 ~$ cat /etc/redhat-release 
Fedora release 22 (Twenty Two)

--- Additional comment from Laurentiu Pancescu on 2016-10-21 18:46:04 EDT ---

(In reply to Petr Matousek from comment #13)
> Please note that this mitigation disables ptrace functionality which
> debuggers and programs that inspect other processes (virus scanners)
> use and thus these programs won't be operational.
> 
> [skipping systemtap-based mitigation]

I was able to reproduce the bug with centos/7 (the latest official Vagrant image of CentOS Linux 7), and I can also confirm that the SystemTap mitigation prevents the original exploit from working.  There are two other POCs now linked from the dirtyc0w GitHub repo, but I didn't test if the SystemTap mitigation also stops them.

As alternatives, I also tried to completely disable ptrace via "sesetbool -P deny_ptrace 1", as well as confining the test user as user_u.  Neither of these stopped the exploit from working.

--- Additional comment from  on 2016-10-21 20:24:17 EDT ---

(In reply to Joel Smith from comment #23)

> I had to install
> 
>    kernel-devel-$(uname -r)
>    systemtap
>    kernel-debuginfo-$(uname -r)
> 
> before I could get stap to build the module for me. The instructions in
> comment #13 do mention the -debuginfo package, but I had confused -devel and
> -debuginfo and was getting that error until I had both.

On CentOS 7.2, I had to get kernel-debuginfo and kernel-debuginfo-common from http://debuginfo.centos.org rather then the usual repos. Fairly large packages.

The stap script appears to block the POC exploit. But when I killed the script with ctrl-C, and re-tried the POC, the VM my system was running on died. Prior to running stap, the POC appeared to work "normally" - obtained root and exited.

--- Additional comment from Tetsuo Handa on 2016-10-21 22:24:42 EDT ---

(In reply to Petr Matousek from comment #13)
> 1) On the host, save the following in a file with the ".stp" extension:
> 
> probe kernel.function("mem_write").call ? {
>         $count = 0
> }
> 
> probe syscall.ptrace {  // includes compat ptrace as well
>         $request = 0xfff
> }
> 
> probe begin {
>         printk(0, "CVE-2016-5195 mitigation loaded")
> }
> 
> 
> probe end {
>         printk(0, "CVE-2016-5195 mitigation unloaded")
> }

I think the script wants

probe kernel.function("mem_write").return ? {
        $return = %{ -EIO %}
}

part added, for simply overwriting $count with 0 causes
legitimate /proc/self/mem writers (if any) to loop forever
inside the kernel unless SIGKILL is delivered; running

$ for i in `seq 1 1024`; do echo > /proc/self/mem & done

triggers resource consumption.


(In reply to advax from comment #31)
> (In reply to Joel Smith from comment #23)
> 
> > I had to install
> > 
> >    kernel-devel-$(uname -r)
> >    systemtap
> >    kernel-debuginfo-$(uname -r)
> > 
> > before I could get stap to build the module for me. The instructions in
> > comment #13 do mention the -debuginfo package, but I had confused -devel and
> > -debuginfo and was getting that error until I had both.
> 
> On CentOS 7.2, I had to get kernel-debuginfo and kernel-debuginfo-common
> from http://debuginfo.centos.org rather then the usual repos. Fairly large
> packages.

You can do

# yum install systemtap yum-utils
# debuginfo-install kernel-$(uname -r)

to download and install.

--- Additional comment from Wade Mealing on 2016-10-22 03:47:20 EDT ---

Statement:

This issue affects the Linux kernel packages as shipped with Red Hat Enterprise Linux 5, 6, 7 and MRG 2.x. This issue has been rated as having Important security impact. Updates for each affected version are in progress and will be released as soon as possible.

Shipping versions of Fedora are affected and Fedora is aware of this flaw.

For additional information about this flaw, please see https://access.redhat.com/security/vulnerabilities/2706661

--- Additional comment from Tetsuo Handa on 2016-10-22 06:09:54 EDT ---

(In reply to Tetsuo Handa from comment #32)
> I think the script wants
> 
> probe kernel.function("mem_write").return ? {
>         $return = %{ -EIO %}
> }
> 
> part added, for simply overwriting $count with 0 causes
> legitimate /proc/self/mem writers (if any) to loop forever
> inside the kernel unless SIGKILL is delivered; running
> 
> $ for i in `seq 1 1024`; do echo > /proc/self/mem & done
> 
> triggers resource consumption.

I found that it is not looping forever inside the kernel, but
for some reason can't be terminated by entering Ctrl-C from
keyboard.

When the script is running, I can terminate if /bin/echo but
I can't terminate if shell's built-in echo. So, this seems to
be a different problem.

[kumaneko@localhost ~]$ /bin/echo > /proc/self/mem
^C
[kumaneko@localhost ~]$ echo > /proc/self/mem
^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C

--- Additional comment from sde on 2016-10-22 13:07:24 EDT ---

Another exploit that doesn't rely on /proc/self/mem but on ptrace (should work on RHEL5/6) :
https://github.com/dirtycow/dirtycow.github.io/blob/master/pokemon.c

--- Additional comment from Ian Allison on 2016-10-22 18:40:18 EDT ---

(In reply to Tetsuo Handa from comment #32)
> You can do
> 
> # yum install systemtap yum-utils
> # debuginfo-install kernel-$(uname -r)
> 
> to download and install.

On 7.2 this gives me

debuginfo-install kernel-$(uname -r)
Loaded plugins: product-id, rhnplugin
This system is receiving updates from RHN Classic or Red Hat Satellite.
enabling epel-debuginfo
Could not find debuginfo for main pkg: kernel-3.10.0-327.36.2.el7.x86_64
No debuginfo packages available to install


As a more general comment, it's absolutely insane that RedHat are basically silent on this matter, there is no visible timeline or information beyond references to the mitigation above which notes

> Also this mitigation works against the In The Wild (ITW) exploit we are aware of but  > most likely does not mitigate the issue as a whole.

The other large distributions have been patched for days! What is the hold up?

--- Additional comment from Akemi Yagi on 2016-10-22 19:13:50 EDT ---

(In reply to Ian Allison from comment #36)
> (In reply to Tetsuo Handa from comment #32)
> > You can do
> > 
> > # yum install systemtap yum-utils
> > # debuginfo-install kernel-$(uname -r)
> > 
> > to download and install.
> 
> On 7.2 this gives me
> 
> debuginfo-install kernel-$(uname -r)
> Loaded plugins: product-id, rhnplugin
> This system is receiving updates from RHN Classic or Red Hat Satellite.
> enabling epel-debuginfo
> Could not find debuginfo for main pkg: kernel-3.10.0-327.36.2.el7.x86_64
> No debuginfo packages available to install

On my RHEL 7.2 system, it works just fine. 

kernel-debuginfo and kernel-debuginfo-common-x86_64 come from the rhel-7-server-debug-rpms repo, and yum-plugin-auto-update-debug-info from the rhel-7-server-optional-rpms repo.

--- Additional comment from Ian Allison on 2016-10-22 19:26:20 EDT ---

Hi Akemi,

(In reply to Akemi Yagi from comment #37)
> kernel-debuginfo and kernel-debuginfo-common-x86_64 come from the
> rhel-7-server-debug-rpms repo, and yum-plugin-auto-update-debug-info from
> the rhel-7-server-optional-rpms repo.

It looks like my organization doesn't have the debuginfo channels on our satellite server. I guess I'll just have to wait.

Thank you anyway!

-Ian.

--- Additional comment from Phil Porada on 2016-10-23 01:40:56 EDT ---

If it helps anybody, I made an Ansible role based off the work from https://gryzli.info/2016/10/21/protect-cve-2016-5195-dirtycow-centos-7rhel7cpanelcloudlinux/.

The Ansible role is located at https://github.com/pgporada/ansible-role-cve. It's idempotent fwiw. I've run it across my fleet of servers running Cent7 with the latest kernel and haven't noticed any ill effects.

--- Additional comment from Karapuzo on 2016-10-23 03:30:33 EDT ---

I am using kernel-ml 4.6.4-1 from elrepo, Centos 7.2.1511

When running debuginfo-install kernel-ml-$(uname -r) I get

Could not find debuginfo for main pkg: kernel-ml-4.6.4-1.el7.elrepo.x86_64

There does not seem to be debuginfo packages for ml kernels from elrepo.
When running stap I get:

[root@CentOS-71-64-minimal dirtycow]# stap -g cow.stp
semantic error: while resolving probe point: identifier 'syscall' at cow.stp:5:7
        source: probe syscall.ptrace {  // includes compat ptrace as well
                      ^

semantic error: no match

Pass 2: analysis failed.  [man error::pass2]


Any way to get around this?

--- Additional comment from Mathieu Parent on 2016-10-23 04:08:07 EDT ---

(In reply to Ed Carp from comment #26)
> I wasn't able to get this to work on RHEL 6.8 or 7.2:
> 
> [erc@lhqseltstut02 root]$ ls -l foo
> -rw-r--r--. 1 root root 0 Oct 21 09:32 foo
[...]
> [erc@lhqseltstut02 root]$ ./dirtyc0w foo m00000000000000000
> mmap ffffffff
> 
[...]

The file should have a > 0 size, otherwise mmap fails (-1).

--- Additional comment from Mathieu Parent on 2016-10-23 04:11:41 EDT ---

(In reply to Michael Carlson from comment #24)
> (In reply to Drew Sears from comment #21)
> > (In reply to Petr Matousek from comment #16)
> > > The in the wild exploit we are aware of doesn't work on Red Hat Enterprise
> > > Linux 5 and 6 out of the box because on one side of the race it writes to
> > > /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise
> > > Linux 5 and 6.
> > 
> > But it does work on RHEL 7?
> 
> I just tested this, and the exploit works on 7.

Does someone know why /proc/self/mem was made writable in RHEL7? Is this required by a RHEL package or some proprietary product? (or was this patch lost during the v7 cycle?)

--- Additional comment from Akemi Yagi on 2016-10-23 09:11:14 EDT ---

(In reply to Karapuzo from comment #40)
> I am using kernel-ml 4.6.4-1 from elrepo, Centos 7.2.1511
> 
> When running debuginfo-install kernel-ml-$(uname -r) I get
> 
> Could not find debuginfo for main pkg: kernel-ml-4.6.4-1.el7.elrepo.x86_64
> 
> There does not seem to be debuginfo packages for ml kernels from elrepo.

> Any way to get around this?

Yes, just update your kernel-ml to the latest version (v4.8.4). It contains the upstream (kernel.org) patch that fixes the bug.

--- Additional comment from Rob Mangiafico on 2016-10-23 14:14:49 EDT ---

Hopefully RH has a patch today... One vulnerable WordPress install that allows a remote file upload and any server is rooted... All other vendors have patches available it seems...

--- Additional comment from Rahimian on 2016-10-23 18:39:21 EDT ---

(In reply to Laurentiu Pancescu from comment #30)
> (In reply to Petr Matousek from comment #13)
> > Please note that this mitigation disables ptrace functionality which
> > debuggers and programs that inspect other processes (virus scanners)
> > use and thus these programs won't be operational.
> > 
> > [skipping systemtap-based mitigation]
> 
> I was able to reproduce the bug with centos/7 (the latest official Vagrant
> image of CentOS Linux 7), and I can also confirm that the SystemTap
> mitigation prevents the original exploit from working.  There are two other
> POCs now linked from the dirtyc0w GitHub repo, but I didn't test if the
> SystemTap mitigation also stops them.
> 
> As alternatives, I also tried to completely disable ptrace via "sesetbool -P
> deny_ptrace 1", as well as confining the test user as user_u.  Neither of
> these stopped the exploit from working.

Your alternative way only work on CentOS 7 
when i run this command (sesetbool -P deny_ptrace 1") on centos 5 or 6 i see this error :
Boolean deny_ptrace is not defined

do you have alternative way for centos 5 and 6
thanks

--- Additional comment from Laurentiu Pancescu on 2016-10-23 19:58:09 EDT ---

(In reply to Rahimian from comment #46)
> (In reply to Laurentiu Pancescu from comment #30)
> > Neither of these stopped the exploit from working.

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Your alternative way only work on CentOS 7

No, it doesn't work in the sense of being a workaround for this bug, and I never claimed it would be an alternative solution (see above).
 
> when i run this command (sesetbool -P deny_ptrace 1") on centos 5 or 6 i see
> this error :
> Boolean deny_ptrace is not defined
> 
> do you have alternative way for centos 5 and 6
> thanks

Disabling ptrace didn't prevent privilege escalation to root using this particular kernel bug in my own tests, therefore it is _NOT_ an alternative workaround.  Petr's SystemTap workaround from comment #13 is the only reliable solution I'm aware of, until an updated kernel will be made available.

Full disclosure: I am _not_ a kernel or SELinux expert and I don't work for RedHat.

--- Additional comment from David Collins on 2016-10-24 02:01:10 EDT ---

(In reply to Mathieu Parent from comment #42)
> (In reply to Michael Carlson from comment #24)
> > (In reply to Drew Sears from comment #21)
> > > (In reply to Petr Matousek from comment #16)
> > > > The in the wild exploit we are aware of doesn't work on Red Hat Enterprise
> > > > Linux 5 and 6 out of the box because on one side of the race it writes to
> > > > /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise
> > > > Linux 5 and 6.
> > > 
> > > But it does work on RHEL 7?
> > 
> > I just tested this, and the exploit works on 7.
> 
> Does someone know why /proc/self/mem was made writable in RHEL7? Is this
> required by a RHEL package or some proprietary product? (or was this patch
> lost during the v7 cycle?)

It wasn't due to any sort of proprietary product or RHEL package.  Back in 2011, there was a commit to allow mem_write to be allowed again.  Prior to that commit, there was a define of mem_write NULL.

There was an initial security reason why it was blocked, but that was fixed.

For more information on the commits I'm referring to, go here http://lists.openwall.net/linux-kernel/2011/03/03/54

--- Additional comment from errata-xmlrpc on 2016-10-24 09:31:42 EDT ---

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2016:2098 https://rhn.redhat.com/errata/RHSA-2016-2098.html

--- Additional comment from Rahimian on 2016-10-24 16:59:42 EDT ---

(In reply to Petr Matousek from comment #13)
> Please note that this mitigation disables ptrace functionality which
> debuggers and programs that inspect other processes (virus scanners)
> use and thus these programs won't be operational.
> 
> Also this mitigation works against the In The Wild (ITW) exploit we are
> aware of but most likely does not mitigate the issue as a whole.
> 
> To mitigate the issue:
> 
> 
> 1) On the host, save the following in a file with the ".stp" extension:
> 
> probe kernel.function("mem_write").call ? {
>         $count = 0
> }
> 
> probe syscall.ptrace {  // includes compat ptrace as well
>         $request = 0xfff
> }
> 
> probe begin {
>         printk(0, "CVE-2016-5195 mitigation loaded")
> }
> 
> 
> probe end {
>         printk(0, "CVE-2016-5195 mitigation unloaded")
> }
> 
> 
> 2) Install the "systemtap" package and any required dependencies. Refer
> to the "2. Using SystemTap" chapter in the Red Hat Enterprise Linux
> "SystemTap Beginners Guide" document, available from docs.redhat.com,
> for information on installing the required -debuginfo and matching
> kernel-devel packages
> 
> 3) Run the "stap -g [filename-from-step-1].stp" command as root.
> 
> If the host is rebooted, the changes will be lost and the script must be
> run again.
> 
> 
> Alternatively, build the systemtap script on a development system with
> "stap -g -p 4 [filename-from-step-1].stp", distribute the resulting
> kernel module to all affected systems, and run "staprun -L <module>" on
> those.
> When using this approach only systemtap-runtime package is required on
> the affected systems. Please notice that the kernel version must be the same
> across all systems.

Hi
when i run stap -g update.stp i see this error :

semantic error: while resolving probe point: identifier 'syscall' at update.stp:5:7
        source: probe syscall.ptrace {  // includes compat ptrace as well
                      ^

semantic error: no match

Pass 2: analysis failed.  [man error::pass2]

how can i fix this error

--- Additional comment from Rahimian on 2016-10-24 17:36:22 EDT ---

(In reply to errata-xmlrpc from comment #49)
> This issue has been addressed in the following products:
> 
>   Red Hat Enterprise Linux 7
> 
> Via RHSA-2016:2098 https://rhn.redhat.com/errata/RHSA-2016-2098.html

i updated my server kernel to 3.10.0-327.36.2.el7

but vulnerability until remained 

./rh-cve-2016-5195_1.sh
Your kernel is 3.10.0-327.36.2.el7.x86_64 which IS vulnerable.
Red Hat recommends that you update your kernel. Alternatively, you can apply partial
mitigation described at https://access.redhat.com/security/vulnerabilities/2706661 .

--- Additional comment from Andrew Thomas on 2016-10-24 17:44:56 EDT ---

(In reply to Rahimian from comment #53)
> (In reply to errata-xmlrpc from comment #49)
> > This issue has been addressed in the following products:
> > 
> >   Red Hat Enterprise Linux 7
> > 
> > Via RHSA-2016:2098 https://rhn.redhat.com/errata/RHSA-2016-2098.html
> 
> i updated my server kernel to 3.10.0-327.36.2.el7
> 
> but vulnerability until remained 
> 
> ./rh-cve-2016-5195_1.sh
> Your kernel is 3.10.0-327.36.2.el7.x86_64 which IS vulnerable.
> Red Hat recommends that you update your kernel. Alternatively, you can apply
> partial
> mitigation described at
> https://access.redhat.com/security/vulnerabilities/2706661 .

You need to update to 3.10.0-327.36.3.el7.x86_64, which just came out today.

--- Additional comment from David Collins on 2016-10-24 20:32:12 EDT ---

(In reply to Rahimian from comment #52)
> (In reply to Petr Matousek from comment #13)
> > Please note that this mitigation disables ptrace functionality which
> > debuggers and programs that inspect other processes (virus scanners)
> > use and thus these programs won't be operational.
> > 
> > Also this mitigation works against the In The Wild (ITW) exploit we are
> > aware of but most likely does not mitigate the issue as a whole.
> > 
> > To mitigate the issue:
> > 
> > 
> > 1) On the host, save the following in a file with the ".stp" extension:
> > 
> > probe kernel.function("mem_write").call ? {
> >         $count = 0
> > }
> > 
> > probe syscall.ptrace {  // includes compat ptrace as well
> >         $request = 0xfff
> > }
> > 
> > probe begin {
> >         printk(0, "CVE-2016-5195 mitigation loaded")
> > }
> > 
> > 
> > probe end {
> >         printk(0, "CVE-2016-5195 mitigation unloaded")
> > }
> > 
> > 
> > 2) Install the "systemtap" package and any required dependencies. Refer
> > to the "2. Using SystemTap" chapter in the Red Hat Enterprise Linux
> > "SystemTap Beginners Guide" document, available from docs.redhat.com,
> > for information on installing the required -debuginfo and matching
> > kernel-devel packages
> > 
> > 3) Run the "stap -g [filename-from-step-1].stp" command as root.
> > 
> > If the host is rebooted, the changes will be lost and the script must be
> > run again.
> > 
> > 
> > Alternatively, build the systemtap script on a development system with
> > "stap -g -p 4 [filename-from-step-1].stp", distribute the resulting
> > kernel module to all affected systems, and run "staprun -L <module>" on
> > those.
> > When using this approach only systemtap-runtime package is required on
> > the affected systems. Please notice that the kernel version must be the same
> > across all systems.
> 
> Hi
> when i run stap -g update.stp i see this error :
> 
> semantic error: while resolving probe point: identifier 'syscall' at
> update.stp:5:7
>         source: probe syscall.ptrace {  // includes compat ptrace as well
>                       ^
> 
> semantic error: no match
> 
> Pass 2: analysis failed.  [man error::pass2]
> 
> how can i fix this error

That issue usually occurs when you don't have the debuginfo RPM.  Try this..

yum install --enablerepo='base-debuginfo' -y kernel-devel-$(uname -r) systemtap kernel-debuginfo-$(uname -r) kernel-devel-$(uname -r)

--- Additional comment from Trevor Jay on 2016-10-24 21:18:51 EDT ---

Just for the record: despite on-line noise to the contrary, unprivileged containers are not vulnerable to vDSO-based attacks. These require ptrace the cap for which is blocked in the OCI defaults.

--- Additional comment from cornel panceac on 2016-10-25 05:17:47 EDT ---

It also works on Fedora 25 x64.

--- Additional comment from Robert Scheck on 2016-10-25 07:07:12 EDT ---

(In reply to sde from comment #35)
> Another exploit that doesn't rely on /proc/self/mem but on ptrace (should
> work on RHEL5/6) :
> https://github.com/dirtycow/dirtycow.github.io/blob/master/pokemon.c

Given this exploit works on at least RHEL 6 with 2.6.32-642.6.1.el6.x86_64,
could somebody please comment when RHEL 6 (and 5) will receive updates?

Additionally cross-filed case 01727522 on the Red Hat customer portal now.

--- Additional comment from Christian Anthon on 2016-10-25 09:16:02 EDT ---

(In reply to Robert Scheck from comment #60)
> (In reply to sde from comment #35)
> > Another exploit that doesn't rely on /proc/self/mem but on ptrace (should
> > work on RHEL5/6) :
> > https://github.com/dirtycow/dirtycow.github.io/blob/master/pokemon.c
> 

Has anybody actually confirmed by personal experience that this or other exploits actually works on RHEL 5 or RHEL 6? It would be "nice" to have working examples to check if the mitigation is working on these systems.

--- Additional comment from Rob Mangiafico on 2016-10-25 09:26:34 EDT ---

(In reply to Christian Anthon from comment #61)
> (In reply to Robert Scheck from comment #60)
> > (In reply to sde from comment #35)
> > > Another exploit that doesn't rely on /proc/self/mem but on ptrace (should
> > > work on RHEL5/6) :
> > > https://github.com/dirtycow/dirtycow.github.io/blob/master/pokemon.c
> > 
> 
> Has anybody actually confirmed by personal experience that this or other
> exploits actually works on RHEL 5 or RHEL 6? It would be "nice" to have
> working examples to check if the mitigation is working on these systems.

Yes, works on RHEL 5/6 that are not patched. Once patched, the vulnerability does not work.

--- Additional comment from nucleo on 2016-10-25 16:14:44 EDT ---

(In reply to errata-xmlrpc from comment #49)
> This issue has been addressed in the following products:
> 
>   Red Hat Enterprise Linux 7
> 
> Via RHSA-2016:2098 https://rhn.redhat.com/errata/RHSA-2016-2098.html

What plans for releasing fixed EL6 kernel?

--- Additional comment from Tetsuo Handa on 2016-10-25 16:56:54 EDT ---

(In reply to nucleo from comment #63)
> (In reply to errata-xmlrpc from comment #49)
> > This issue has been addressed in the following products:
> > 
> >   Red Hat Enterprise Linux 7
> > 
> > Via RHSA-2016:2098 https://rhn.redhat.com/errata/RHSA-2016-2098.html
> 
> What plans for releasing fixed EL6 kernel?

Already available as 2.6.32-642.6.2.el6. See "Resolve" tab at https://access.redhat.com/security/vulnerabilities/2706661 .

--- Additional comment from Andrew Thomas on 2016-10-25 17:00:16 EDT ---

(In reply to Tetsuo Handa from comment #64)
> (In reply to nucleo from comment #63)
> > (In reply to errata-xmlrpc from comment #49)
> > > This issue has been addressed in the following products:
> > > 
> > >   Red Hat Enterprise Linux 7
> > > 
> > > Via RHSA-2016:2098 https://rhn.redhat.com/errata/RHSA-2016-2098.html
> > 
> > What plans for releasing fixed EL6 kernel?
> 
> Already available as 2.6.32-642.6.2.el6. See "Resolve" tab at
> https://access.redhat.com/security/vulnerabilities/2706661 .

Although they say it is available, it doesn't appear to actually be available yet. Everything I tried still shows 2.6.32-642.6.1 as the latest kernel.

--- Additional comment from David Collins on 2016-10-25 17:11:25 EDT ---

(In reply to Andrew Thomas from comment #65)
> (In reply to Tetsuo Handa from comment #64)
> > (In reply to nucleo from comment #63)
> > > (In reply to errata-xmlrpc from comment #49)
> > > > This issue has been addressed in the following products:
> > > > 
> > > >   Red Hat Enterprise Linux 7
> > > > 
> > > > Via RHSA-2016:2098 https://rhn.redhat.com/errata/RHSA-2016-2098.html
> > > 
> > > What plans for releasing fixed EL6 kernel?
> > 
> > Already available as 2.6.32-642.6.2.el6. See "Resolve" tab at
> > https://access.redhat.com/security/vulnerabilities/2706661 .
> 
> Although they say it is available, it doesn't appear to actually be
> available yet. Everything I tried still shows 2.6.32-642.6.1 as the latest
> kernel.

Its available.  If you're using RHEL6 you should be able to `yum update` at this point and it should update.  Maybe you're using CentOS 6?  If so, you're going to have to wait until they push and update to their repos.

RHEL provides public SRPMs for all of their packages, and its definately in their SRPM Repo ( http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/kernel-2.6.32-642.6.2.el6.src.rpm )

If you are running RHEL6, maybe try to clear your yum cache by running `yum clean all`

--- Additional comment from Robert Scheck on 2016-10-25 17:19:52 EDT ---

I am sorry, but speaking up as a paying RHEL customer, I still can not see
the mentioned update 2.6.32-642.6.2.el6 on any of my systems, while each of
the systems is directly connected to RHSM. It feels like the Red Hat CDN is
not yet in sync or so. Interestingly the e-mail for RHSA-2016-2105 did not
arrive here yet, too.

--- Additional comment from Andrew Thomas on 2016-10-25 17:34:29 EDT ---


> > 
> > Although they say it is available, it doesn't appear to actually be
> > available yet. Everything I tried still shows 2.6.32-642.6.1 as the latest
> > kernel.
> 
> Its available.  If you're using RHEL6 you should be able to `yum update` at
> this point and it should update.  Maybe you're using CentOS 6?  If so,
> you're going to have to wait until they push and update to their repos.
> 
> RHEL provides public SRPMs for all of their packages, and its definately in
> their SRPM Repo (
> http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/kernel-2.6.
> 32-642.6.2.el6.src.rpm )
> 
> If you are running RHEL6, maybe try to clear your yum cache by running `yum
> clean all`

I am running RHEL6.  Earlier today I used yum to update to kernel-2.6.32-642.6.1.el6.x86_64.  I have been using "yum clean all" and yum update, but it says there are no updates available.

I went to the Customer Portal Downloads area.  It also shows that 2.6.32-642.6.1 is the latest, and 2.6.32-642.6.2 is not there.

--- Additional comment from Clifford Perry on 2016-10-25 17:57:17 EDT ---

(In reply to Andrew Thomas from comment #68)
> > > 
> > > Although they say it is available, it doesn't appear to actually be
> > > available yet. Everything I tried still shows 2.6.32-642.6.1 as the latest
> > > kernel.
> > 
> > Its available.  If you're using RHEL6 you should be able to `yum update` at
> > this point and it should update.  Maybe you're using CentOS 6?  If so,
> > you're going to have to wait until they push and update to their repos.
> > 
> > RHEL provides public SRPMs for all of their packages, and its definately in
> > their SRPM Repo (
> > http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/kernel-2.6.
> > 32-642.6.2.el6.src.rpm )
> > 
> > If you are running RHEL6, maybe try to clear your yum cache by running `yum
> > clean all`
> 
> I am running RHEL6.  Earlier today I used yum to update to
> kernel-2.6.32-642.6.1.el6.x86_64.  I have been using "yum clean all" and yum
> update, but it says there are no updates available.
> 
> I went to the Customer Portal Downloads area.  It also shows that
> 2.6.32-642.6.1 is the latest, and 2.6.32-642.6.2 is not there.


Hi Andrew and David - please be aware that bugzilla is not a support tool. Additionally a LOT of people are cc'd on this bugzilla. 

The RHEL 6.8.z Errata is in progress - which explains why some are seeing it and others are not. When the push process is completed and sanity checked we then mark it formally as live. 

If you have specific issues that need investigating, please open a support case with Red Hat Support within the Customer Portal http://access.redhat.com/ 
 - While right now, I assume it is because the bits are in-progress, there are multiple reasons (for fully live Errata/RPMs) for failure, and experienced members of our staff can help to diagnose the cause and appropriately report internally (if needed) to that team, or to assist specific customers with potentially local issues in the customers environment. 

Regards,
Cliff

--- Additional comment from san on 2016-10-25 20:53:54 EDT ---

am i the only getting gpg error in both

existing kernel
2.6.32-431.el6.x86_64 and 2.6.32.621

Src rpm
kernel-2.6.32-642.6.2.el6.src.rpm

+ cp /root/rpmbuild/SOURCES/extrakeys.pub .
+ cat
###
### Now generating a PGP key pair to be used for signing modules.
###
### If this takes a long time, you might wish to run rngd in the background to
### keep the supply of entropy topped up.  It needs to be run as root, and
### should use a hardware random number generator if one is available, eg:
###
###     rngd -r /dev/hwrandom
###
### If one isn't available, the pseudo-random number generator can be used:
###
###     rngd -r /dev/urandom
###
+ gpg --homedir . --batch --gen-key /root/rpmbuild/SOURCES/genkey
gpg: WARNING: unsafe permissions on homedir `.'
gpg: keyring `./secring.gpg' created
gpg: keyring `./pubring.gpg' created
gpg: WARNING: some OpenPGP programs can't handle a DSA key with this digest size

?

--- Additional comment from san on 2016-10-25 20:54:29 EDT ---

am i the only getting gpg error in both

existing kernel
2.6.32-431.el6.x86_64 and 2.6.32.621

Src rpm
kernel-2.6.32-642.6.2.el6.src.rpm

+ cp /root/rpmbuild/SOURCES/extrakeys.pub .
+ cat
###
### Now generating a PGP key pair to be used for signing modules.
###
### If this takes a long time, you might wish to run rngd in the background to
### keep the supply of entropy topped up.  It needs to be run as root, and
### should use a hardware random number generator if one is available, eg:
###
###     rngd -r /dev/hwrandom
###
### If one isn't available, the pseudo-random number generator can be used:
###
###     rngd -r /dev/urandom
###
+ gpg --homedir . --batch --gen-key /root/rpmbuild/SOURCES/genkey
gpg: WARNING: unsafe permissions on homedir `.'
gpg: keyring `./secring.gpg' created
gpg: keyring `./pubring.gpg' created
gpg: WARNING: some OpenPGP programs can't handle a DSA key with this digest size

?

--- Additional comment from errata-xmlrpc on 2016-10-26 05:07:24 EDT ---

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6.7 Extended Update Support

Via RHSA-2016:2106 https://rhn.redhat.com/errata/RHSA-2016-2106.html

--- Additional comment from errata-xmlrpc on 2016-10-26 06:48:21 EDT ---

This issue has been addressed in the following products:

  MRG for RHEL-6 v.2

Via RHSA-2016:2107 https://rhn.redhat.com/errata/RHSA-2016-2107.html

--- Additional comment from Joao Matos on 2016-10-26 06:57:03 EDT ---

tks guys

--- Additional comment from errata-xmlrpc on 2016-10-26 07:42:50 EDT ---

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2016:2105 https://rhn.redhat.com/errata/RHSA-2016-2105.html

--- Additional comment from errata-xmlrpc on 2016-10-26 08:23:18 EDT ---

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2016:2110 https://rhn.redhat.com/errata/RHSA-2016-2110.html

--- Additional comment from errata-xmlrpc on 2016-10-26 14:55:10 EDT ---

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7.1 Extended Update Support

Via RHSA-2016:2118 https://rhn.redhat.com/errata/RHSA-2016-2118.html

--- Additional comment from J W on 2016-10-26 23:01:07 EDT ---

Thanks for the kernel updates for RHEL6 and RHEL7.

When can we expect a fix for Red Hat Enterprise Linux RHEL5?  We have dozens of live production systems on RHEL5 and need this fix asap.  Hopefully it is being worked on with the same urgency?

Thanks!

--- Additional comment from errata-xmlrpc on 2016-10-27 05:08:28 EDT ---

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6.5 Advanced Update Support
  Red Hat Enterprise Linux 6.5 Telco Extended Update Support

Via RHSA-2016:2120 https://rhn.redhat.com/errata/RHSA-2016-2120.html

--- Additional comment from Binglin Ji on 2016-10-27 05:22:15 EDT ---

Thanks for the kernel updates for RHEL6 and RHEL7.

One of my customer has many production systems running on RHEL6.3 and need this fix. but from our published page https://access.redhat.com/security/vulnerabilities/2706661. No RHEL 6.3 fix plan on it. 

Are we going to fix it for RHEL 6.3 in AUS ? Thanks~