This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 1384344 - (CVE-2016-5195, DirtyCow) CVE-2016-5195 kernel: mm: privilege escalation via MAP_PRIVATE COW breakage
CVE-2016-5195 kernel: mm: privilege escalation via MAP_PRIVATE COW breakage
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
impact=important,public=20161019,repo...
: Security
Depends On: 1385129 1385112 1385113 1385115 1385116 1385117 1385118 1385119 1385120 1385121 1385122 1385123 1385124 1385125 1385126 1385127 1385128 1386215 1386756 1387080 1387081 1387427 1387735 1387737 1387738 1387744 1387745 1387748 1387749 1387778 1387781 1387818 1388654 1396582 1402109 1422636
Blocks: 1384346
  Show dependency treegraph
 
Reported: 2016-10-13 03:45 EDT by Andrej Nemec
Modified: 2017-03-02 12:08 EST (History)
156 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
A race condition was found in the way the Linux kernel's memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings. 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.
Story Points: ---
Clone Of:
: 1387735 1387737 1389260 (view as bug list)
Environment:
Last Closed: 2016-11-08 05:20:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2720521 None None None 2016-10-23 20:52 EDT

  None (edit)
Description Andrej Nemec 2016-10-13 03:45:13 EDT
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
Comment 13 Petr Matousek 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.
Comment 15 Petr Matousek 2016-10-19 12:38:05 EDT
Acknowledgements:

Name: Phil Oester
Comment 16 Petr Matousek 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.
Comment 19 Kurt Seifried 2016-10-19 23:25:17 EDT
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1387080]
Comment 20 Petr Matousek 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.
Comment 21 Drew Sears 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?
Comment 23 Joel Smith 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.
Comment 24 Michael Carlson 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.
Comment 26 Ed Carp 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?
Comment 28 Ed Carp 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)
Comment 30 Laurentiu Pancescu 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.
Comment 31 advax 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.
Comment 32 Tetsuo Handa 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.
Comment 33 Wade Mealing 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
Comment 34 Tetsuo Handa 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
Comment 35 sde 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
Comment 36 Ian Allison 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?
Comment 37 Akemi Yagi 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.
Comment 38 Ian Allison 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.
Comment 39 Phil Porada 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.
Comment 40 Karapuzo 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?
Comment 41 Mathieu Parent 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).
Comment 42 Mathieu Parent 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?)
Comment 43 Akemi Yagi 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.
Comment 45 Rob Mangiafico 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...
Comment 46 Rahimian 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
Comment 47 Laurentiu Pancescu 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.
Comment 48 David Collins 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
Comment 49 errata-xmlrpc 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
Comment 52 Rahimian 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
Comment 53 Rahimian 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 .
Comment 54 Andrew Thomas 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.
Comment 55 David Collins 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)
Comment 56 Trevor Jay 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.
Comment 58 cornel panceac 2016-10-25 05:17:47 EDT
It also works on Fedora 25 x64.
Comment 60 Robert Scheck 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.
Comment 61 Christian Anthon 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.
Comment 62 Rob Mangiafico 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.
Comment 63 nucleo 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?
Comment 64 Tetsuo Handa 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 .
Comment 65 Andrew Thomas 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.
Comment 66 David Collins 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`
Comment 67 Robert Scheck 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.
Comment 68 Andrew Thomas 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.
Comment 69 Clifford Perry 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
Comment 70 san 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

?
Comment 71 san 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

?
Comment 73 errata-xmlrpc 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
Comment 74 errata-xmlrpc 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
Comment 75 Joao Matos 2016-10-26 06:57:03 EDT
tks guys
Comment 76 errata-xmlrpc 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
Comment 77 errata-xmlrpc 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
Comment 78 errata-xmlrpc 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
Comment 79 J W 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!
Comment 81 errata-xmlrpc 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
Comment 85 errata-xmlrpc 2016-10-28 05:29:32 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 5

Via RHSA-2016:2124 https://rhn.redhat.com/errata/RHSA-2016-2124.html
Comment 86 errata-xmlrpc 2016-10-31 07:30:26 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 5.6 Long Life

Via RHSA-2016:2127 https://rhn.redhat.com/errata/RHSA-2016-2127.html
Comment 87 errata-xmlrpc 2016-10-31 07:31:57 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 5.9 Long Life

Via RHSA-2016:2126 https://rhn.redhat.com/errata/RHSA-2016-2126.html
Comment 88 errata-xmlrpc 2016-10-31 12:02:40 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6.6 Extended Update Support

Via RHSA-2016:2128 https://rhn.redhat.com/errata/RHSA-2016-2128.html
Comment 89 errata-xmlrpc 2016-11-01 06:59:02 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6.4 Advanced Update Support

Via RHSA-2016:2133 https://rhn.redhat.com/errata/RHSA-2016-2133.html
Comment 90 errata-xmlrpc 2016-11-01 09:24:35 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6.2 Advanced Update Support

Via RHSA-2016:2132 https://rhn.redhat.com/errata/RHSA-2016-2132.html
Comment 94 stefano gristina 2016-12-05 09:33:20 EST
The bug is still not solved.

With the following kernel release it's still possible to get root privileges from a normal linux user.

[xxx@xxx xxx]#  uname -a
Linux xxx 2.6.32-642.11.1.el6.x86_64 #1 SMP Tue Nov 15 09:40:59 PST 2016 x86_64 x86_64 x86_64 GNU/Linux)

Best Regards

Stefano
Comment 95 Clifford Perry 2016-12-05 09:42:37 EST
(In reply to stefano gristina from comment #94)
> The bug is still not solved.
> 
> With the following kernel release it's still possible to get root privileges
> from a normal linux user.
> 
> [xxx@xxx xxx]#  uname -a
> Linux xxx 2.6.32-642.11.1.el6.x86_64 #1 SMP Tue Nov 15 09:40:59 PST 2016
> x86_64 x86_64 x86_64 GNU/Linux)
> 
> Best Regards
> 
> Stefano

Hi Stefano, 
Can you please contact secalert@redhat.com with any details. To my knowledge this is not the case and maybe user error. But let us communicate with you in private to investigate the details. If you wish to use GPG - our details can be found here: 

https://access.redhat.com/security/team/contact/

Regards,
Cliff
Comment 96 stefano gristina 2016-12-05 10:11:17 EST
Done. 

Best Regards

Stefano
Comment 99 errata-xmlrpc 2017-03-02 12:08:48 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2017:0372 https://rhn.redhat.com/errata/RHSA-2017-0372.html

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