What Dirty COW was

Dirty COW, tracked as CVE-2016-5195, was a race condition in the way the Linux kernel handled copy-on-write memory. A local user, or a compromised website process, could use it to write to files that should have been read-only, and from there gain root access. The flaw had been in the kernel for about nine years before it was found and fixed in October 2016.

The name comes from “copy-on-write”, shortened to COW. It became one of the best-known Linux flaws because public exploits were easy to use and worked on most servers of the time.

Is my server still affected?

Almost certainly not, if the server runs a supported release and gets updates. Any kernel from a supported distribution released after late 2016 includes the fix. You are only at risk on a very old system that has not been updated since, such as CentOS 6 or an early CentOS 7 kernel. Those systems have other, newer flaws too, and should be replaced.

Newer kernel flaws that work the same way

These flaws all need local access first, for example through a hacked website, a stolen SSH login, or another customer on a shared server. That is why they matter most on shared hosting servers and on servers that run code you do not fully trust.

How attackers use kernel flaws

A kernel flaw is usually the second step of an attack, not the first. A typical chain looks like this:

1. The attacker breaks into a website, for example through an outdated plugin, and gets a shell as the website user.
2. They run an exploit for a kernel flaw to turn that limited account into root.
3. With root, they can hide files, add users, read every site on the server, or install malware.

Signs that this may have happened include new user accounts, unknown cron jobs, changed system files, and processes you do not recognise. Tools such as rkhunter and Linux Malware Detect help you check. If you find signs of a root compromise, the safest fix is a clean rebuild from known-good backups.

Containers, VPS and the kernel

• KVM virtual servers run their own kernel. Patch the kernel inside your VPS, just as you would on a physical server.
• Containers such as Docker share the host’s kernel. Updating the container image does not fix a kernel flaw: the host kernel must be patched.
• Virtualisation hosts need extra care. A flaw like JanusCape affects the host kernel, so the provider must patch the host.

Step 1: check your running kernel

# The kernel that is running now
uname -r

# Your distribution and release
cat /etc/os-release

Compare the version with your distribution’s security notice for the flaw you are checking.

Step 2: update the kernel

AlmaLinux, Rocky Linux, RHEL and CloudLinux

sudo dnf upgrade kernel

# Has a newer kernel been installed than the one running?
sudo dnf install -y dnf-utils
sudo needs-restarting -r

Debian and Ubuntu

sudo apt update && sudo apt upgrade

# Ubuntu and Debian create this file when a reboot is needed
ls /var/run/reboot-required && cat /var/run/reboot-required

Step 3: make the new kernel run

Installing a kernel update does not protect you until the server runs the new kernel. You have two options:

• Reboot. The simplest and most reliable option. Plan a short maintenance window, then check uname -r again.
• Live patching. Services such as KernelCare, Canonical Livepatch on Ubuntu, or kpatch on RHEL-based systems apply security fixes to the running kernel without a reboot. They are useful for servers that cannot go down often. You still reboot onto a full kernel update from time to time.

Step 4: confirm the fix

uname -r                     # should show the new kernel version
sudo needs-restarting -r     # RHEL family: should say no reboot is needed

On Ubuntu and Debian, the /var/run/reboot-required file should be gone after the reboot.

Turn on automatic security updates

Automatic updates install fixes as soon as your distribution releases them. You still need to reboot for kernel updates.

# AlmaLinux, Rocky Linux, RHEL, CloudLinux
sudo dnf install -y dnf-automatic
# In /etc/dnf/automatic.conf set: apply_updates = yes
sudo systemctl enable --now dnf-automatic.timer

# Debian and Ubuntu
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

On cPanel servers, keep cPanel updates on as well, in WHM > Update Preferences.

Reduce the risk from the next kernel flaw

• ✓ Install updates automatically, or at least weekly, and reboot after kernel updates.
• ✓ Keep websites and plugins updated, because a hacked site is the usual way attackers get local access.
• ✓ Disable SSH password logins and use keys, so stolen passwords are less useful.
• ✓ On shared servers, use account isolation such as CloudLinux CageFS.
• ✓ Subscribe to your distribution’s security announcements.

For hands-on hardening, see our CSF firewall guide and our cPanel security tips.