Kernel Local Privilege Escalation "Dirty COW" - CVE-2016-5195

Public Date: October 19, 2016, 12:00 am
Updated -
Resolved Status
Important Impact

Red Hat Product Security has been made aware of a vulnerability in the Linux kernel that has been assigned CVE-2016-5195. This issue was publicly disclosed on October 19, 2016 and has been rated as Important. This issue is being refered to as "Dirty COW" in the media.

Background Information

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.

This could be abused by an attacker to modify existing setuid files with instructions to elevate privileges. An exploit using this technique has been found in the wild. This flaw affects most modern Linux distributions.

Red Hat Product Security has rated this update as having a security impact of Important.

Impacted Products

The following Red Hat Product versions are impacted:

  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise MRG 2
  • Red Hat Openshift Online v2
  • Red Hat Virtualization (RHEV-H/RHV-H)

Attack Description and Impact

This flaw allows an attacker with a local system account to modify on-disk binaries, bypassing the standard permission mechanisms that would prevent modification without an appropriate permission set. This is achieved by racing the madvise(MADV_DONTNEED) system call while having the page of the executable mmapped in memory.

Diagnose your vulnerability

Determine if your system is vulnerable

Take Action

All Red Hat customers running the affected versions of the kernel are strongly recommended to update the kernel as soon as patches are available. Details about impacted packages as well as recommended mitigation are noted below. A system reboot is required in order for the kernel update to be applied.

Updates for Affected Products

The fixes for CVE-2016-5195 were included in the recent release of Red Hat Enterprise Linux 7.3.

A kpatch for customers running Red Hat Enterprise Linux 7.2 or greater will be available. Please open a support case to gain access to the kpatch.

For more details about what a kpatch is: Is live kernel patching (kpatch) supported in RHEL 7?

Red Hat Enterprise Linux 7kernelRHSA-2016:2098
Red Hat Enterprise Linux 7kernel-rtRHSA-2016:2110
Red Hat Enterprise Linux 7.1 Extended Update Support*kernelRHSA-2016:2118
Red Hat Enterprise Linux 6kernelRHSA-2016:2105
Red Hat Enterprise Linux 6.7 Extended Update Support*kernelRHSA-2016:2106
Red Hat Enterprise Linux 6.6 Advanced Update Support**kernelRHSA-2016:2128
Red Hat Enterprise Linux 6.5 Advanced Update Support**kernelRHSA-2016:2120
Red Hat Enterprise Linux 6.4 Advanced Update Support**kernelRHSA-2016:2133
Red Hat Enterprise Linux 6.2 Advanced Update Support**kernelRHSA-2016:2132
Red Hat Enterprise Linux 5kernelRHSA-2016:2124
Red Hat Enterprise Linux 5.9 Advanced Update Support**kernelRHSA-2016:2126
Red Hat Enterprise Linux 5.6 Advanced Update Support**kernelRHSA-2016:2127
RHEL Atomic Hostkernelimages respun on 3Nov2016
Red Hat Enterprise MRG 2kernel-rtRHSA-2016:2107
Red Hat Virtualization (RHEV-H/RHV-H)kernelpending

*An active EUS subscription is required for access to this patch.

Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active EUS subscription.

What is the Red Hat Enterprise Linux Extended Update Support Subscription?

**An active AUS subscription is required for access to this patch in RHEL AUS.


Red Hat Support supplies mitigations like SystemTap scripts as a stop-gap until official patches are released.  SystemTap scripts are only supported for 30 days after the GA release of the final patches.


The systemtap countermeasure involves creating a kernel module (like a driver) using a systemtap script that intercepts the vulnerable system call. It is used as a stopgap solution until a fixed kernel is booted into the affected machine. This solution does not require a reboot and applies to RHEL 5, 6 and 7.

It is not possible to make a module that applies to all kernels. Not even for a family (i.e., All RHEL5, 6 or 7). Each specific kernel version requires a .ko generated for that given kernel (uname -r).


In order to build the systemtap module, the following packages are required:

  • systemtap-client
  • systemtap-devel
  • gcc (and dependencies)
  • kernel-devel-`uname -r`
  • kernel-debuginfo-`uname -r`
  • kernel-debuginfo-common-`uname -r`

WARNING: The 'kernel' packages requires the same version as the running kernel. Downloading the latest version will prevent systemtap for working. Please download the exact running version.


Please refer to KB


1. After you installed the packages, create a file named dirtycow.stp with this content:

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. Save the file. Compile it using this command:

# stap -g -p 4 -m dirtycow_`uname -r|tr -cd [:digit:]` dirtycow.stp

In the above example, the .ko file has a number identifying its kernel version. In that case, it is 2.6.18-398.el5. This module can be used in other systems with this exact kernel version without having to install the debuginfo and development packages, needing only systemtap-runtime . Just copy the module file to the server with the same kernel version, install the systemtap-runtime package and proceed from the next step.

3. In order to load the module, run the command staprun -L <.ko file>. For example:

# staprun -L dirtycow_26183985.ko

4. Check if is it loaded:

# dmesg | grep CVE-2016-5195
CVE-2016-5195 mitigation loaded

5. To unload the module, reboot the system or run the "staprun -A dirtycow_26183985" command and interrupt it with Ctlr+C, as shown below:

# staprun -A dirtycow_26183985
Message from syslogd@...
kernel:CVE-2016-5195 mitigation unloaded


  • The module does not survive a boot: It is not reloaded after a system boot.
  • After a reboot, the module must be manually loaded again.
  • If the kernel is updated or changed, this module won't be loaded into the new kernel.
  • If you booted into a different kernel without the fix, a new compatible module should be loaded.
  • A corrected kernel does not need the module load.

Please reference bug 1384344 for detailed mitigation steps.


Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.

Current Customers and Partners

Log in for full access

Log In

The script has an error at line 590.

line 590: "syntax error near unexpected token <' line 590:done < <( dmesg )'

Try running with bash, i.e.:

 $ bash ./

Hi Victor. The script is supposed to be ran with Bash (as specified by shebang). It should work well with any version of Bash provided in RHEL5 and newer. If you still encounter problems, can you let me know what OS and what Bash version are you using? Thanks!

Hello Stanislav ,

I am facing same issue while running this script .

[root@oc8423250611 Desktop]# cat /etc/redhat-release Red Hat Enterprise Linux Workstation release 6.8 (Santiago) [root@oc8423250611 Desktop]# rpm -qa | grep -i bash bash-4.1.2-40.el6.x86_64 [root@oc8423250611 Desktop]#

It is my understading that only "premium" subscrition has kpatch utility, or it is avail also for standard?

kpatch will cover only premium customers using RHEL7, and still you will need to reboot within a month

Hello, Red Hat Product Security has granted an one time exception allowing customer's who do not have premium support to request kpatch packages related to CVE-2016-5195. Please open a support case and reference this URL: for assistance.

I know the folks at Red Hat will be diligently working on this but any indication of time frames for release of the patched kernel?

Hello Darren, I apologize but we can't provide a time frame around releases for security fixes. We are, as you mentioned, of course working diligently to address this issue as quickly as possible.

according to Red Hat BugZilla 1384344 the public exploit only affects 7

--- quote from bugzilla -- 
"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."

will redhat confirm that the issue is not impacting rhel5 and rhel6 servers?

I tried the public exploit on RHEL 5 and 6 without any luck, but RHEL 7 was affected.

To be clear.

"The version caught in the wild" was the version that was detected by Red Hat, not versions written by people post this release. New versions of the same exploit, including the ptrace vector were created after the public release of this flaw.

I'm actually pretty chilled out.

Please look at lines 426-433 of the kernel version verification script. Based on the remainder of the numerals sequence, I do believe these should continue as 3.10 from above and below, not 2.10 as contained at lines 426-433 of the current revision ( It may be warranted to double-check other entries as well.

Hi Ismail. Thanks for noticing this. There was a mistake in the way the tree of vulnerable versions was post-processed. It should be fixed now in a new version of the script.

Am I correct in my assessment that all major Linux vendors have release patched kernels except Redhat?

A kpatch update exists, please contact Red Hat support for access.

Could you please tell us when the kernel patch will be available for Dirty COW ? Also please confirm if RHEL5 and 6 are effected with this vulnerability or not ?

RHEL5 and RHEL6 are vulnerable. However, the in the wild exploit we are aware of doesn't work on RHEL5 and RHEL6 out of the box, see Bugzilla bug for details.

Thanks, So when we can expect a patch ?

Jobin: Regarding RHEL 7.2: Red Hat Support can now provide you with a kpatch (live kernel patch), provided that your RHEL 7.2 installation is running the 3.10.0-327.36.1 or 3.10.0-327.36.2 kernel (more versions may be supported later). I tested the kpatch with the latter version, and it seems to work well.

Troels Arvin: All our customer are running RHEL5 and 6 .

Dear Joseph , Please use the following command to check whether U affected or not :

wget && bash ./

@Andriy Zhylenko , yep i know, even redhat confirmed above.

We actually need the patch, i have no idea why the wait is for :)

Hello Jobin - Patches will be delivered for RHEL5 & 6 over the next several days. Please either select to be updated as content on this page changes or open a support ticket with our CEE team so that they can notify you when the updates are ready.

Due to the fact that the exploit for raising to the root privileges exists, I suppose it is better to increase the priority for creating a patch.

I do agree Andriy. I am pretty sure regarding the Redhat diligence on this issue. We will get the patch in a few days. The best thing to do during the wait time is to detect all affected boxes in your environment and be aware of the security vulnerabilities.

It's intriguing that there is such a long lead time for this patch release, especially considering how long the fix has been available from upstream. Are Red Hat able to provide an update on this?

There is a kpatch update which will protect your system, please contact support for access.

Why kpatch only? why hasn't there been an updated kernel rpm package released?

What is the difference with this kernel update that has made Red Hat change their approach?

Is Satellite kpatch aware?

So to answer each one.

Why kpatch only?

Kpatch has a quicker delivery and turn around time than spinning and qe'ing a whole kernel update.

What is the difference with this kernel update that has made Red Hat change their approach?

The VM subsystem is a relatively complex area (as it is shown how this bug was missed for a long time) and the risk of spinning a released kernel that would have wide-range impact without passing QE would be worse than the kpatch delivery method. (This is just my thoughts on the matter)

Is Satellite kpatch aware?

Red Hat enterprise Linux 7 based software is kpatch aware, so if you're running a super old satellite, it depends on your satellite.


I was referring to Satellite 6 in my last question.

If I patch something using kpatch, does Satellite 6 show this as patched (not vulnerable) from its perspective? or does it still require the taditional kernel rpm to be installed before it will acknowledge that the issue is mitigated?

Sorry for the long delay, I had missed this in the case work. I'm kinda out of scope in regards to how satellite 6 works. I focus on the kernel side of things. I'm going to see if i can talk to satellite expert to find out how it works.

It looks like the kernel rpm has been released yesterday for RHEL7:

Logged a support case to request for the kpatch but support personnel replied the following:

== Begin =====================



Our Engineering Team is actively working on patch for this vulnerability. It is been tracked through public bugzilla:

== End =====================

Is Support aware of supplying the kpatch to customers?

I just had a customer request this last night and they were forwarded the systemtap solution (bugzilla link) and were also provided the kpatch rpms for el7.

Have Red Hat identified additional issues that are causing the delay in the release of the updated kernel rpm?

I opened a case today and they sent me the kpatch even if I'm not a premium customer. The full patched kernel is also available for 7.

If there is no released kernel RPM update for CVE-2016-5195, all RHEL-derived distributions (and anyone who trust security updates will protect them) are vulnerable and unaware. For example, various websites and news articles simply state that you can protect yourself on RHEL and CentOS by installing the latest updates (yum update; reboot). Which is currently not true !

This is not what people expect or have paid for. I do not understand why the known/existing fix is not being backported and released ASAP.

Great to see I am not the only one with concerns.

I know one downstream vendor who rolls their own kernel (hope that narrows it down) has released a patch for their kernel... so the fact it is taking Red Hat so long has me concerned. Support are only providing systemtap and kpatch fixes for this... i'd much prefer to patch customers (once) using the proven process rather than kpatching/systemtap in-memory patching and then going back and doing it again.

Is there a possibility that in resolving this issue they have found another security issue which is now under embargo.. which is why the release for this kernel update is delayed?

That would make the situation very similar to Shellshock with both CVE-2014-6271 and then subsequently CVE-2014-7169 being released. Is this what they are trying to avoid?

P.S. Thanks for mrepo and all your packages Dag. Appreciate your effort and contributions over the last 10+ years.

Hello Dag. Right now we have the patch available for our RHEL7.2.z kernel. Customers can also request a kpatch and run that for a period of time until they can apply the full update.

Updates for all of our other streams are in-flight. More patches for RHEL7.x and 6.x should be arriving soon with work on RHEL 5 fixes being delivered shortly afterwards.

Do we know if update will be applied to RHEL 7.3 before release?

Hi Derek - Yes the fix for CVE-2016-5195 will be included with RHEL 7.3. Patches are available today for RHEL 7.2, with several others on the way behind it.

I am updating new kernel to kernel-3.10.0-327.36.2.el7.x86_64.rpm latest one.

Is that will remove CVE-2016-5195 Vulnerability issue on RHEL7.2 or we have to upgrade with latest one which is available by link given above.

Can we upgrade it manually by running #rpm -Uvh kernel-3.10.0-327.36.2.el7.x86_64.rpm or #rpm -ivh kernel-3.10.0-327.36.2.el7.x86_64.rpm command?

Is CVE-2016-5195 Vulnerability issue related updated kernel package is available for RHEL6 and RHEL5?


That is not the latest kernel package, you need kernel package version kernel-3.10.0-327.36.3.el7.x86_64.rpm (as described on the 'Resolve' page) to resolve this issue in el7.

I suspect there are some delays with this getting out via CDN as I have seen this question multiple times today.

"Can we upgrade it manually by running #rpm -Uvh kernel-3.10.0-327.36.2.el7.x86_64.rpm or #rpm -ivh kernel-3.10.0-327.36.2.el7.x86_64.rpm command?"

Just a friendly note: when updating a kernel using the rpm command, be sure to use the -i flag, not the -U flag.