HowToFixMe
● High · CVSS 7.8 ⚠ ACTIVELY EXPLOITED — CISA KEV

How to Fix CVE-2010-3904: Security Vulnerability in Kernel

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

⚡ At a glance
SeverityCVSS 7.8 - High
Actively exploited?Yes, listed in CISA KEV (added 2023-05-12)
AffectedLinux kernel before 2.6.36 (RDS protocol, net/rds/page.c)
Fixed inLinux kernel 2.6.36 (upstream commit 799c1055); distro backports via RHSA-2010:0792 / USN-1000-1 / SUSE-SA:2010:053
Attack vectorLocal privilege escalation (needs a local account, no remote reach)
Type (CWE)Improper input validation (CWE-20)

Exploitation status

CVE-2010-3904 is actively exploited in the wild. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on as “Linux Kernel Improper Input Validation Vulnerability”, which makes patching mandatory for U.S. federal agencies under Binding Operational Directive 22-01. Federal agencies were required to remediate it by . If you run an affected system, treat this as an emergency change, not a scheduled one.

Public exploit availability: a public exploit on Exploit-DB has been published. Assume opportunistic scanning and weaponization; prioritize accordingly.

Authoritative references:

Patch immediately. CISA's Known Exploited Vulnerabilities catalog lists this CVE, which means active exploitation has been confirmed. CISA KEV entry added 2023-05-12, federal due date 2023-06-02.

What is CVE-2010-3904?

CVE-2010-3904 is a local privilege-escalation flaw in the Linux kernel. The bug lives in rds_page_copy_user in net/rds/page.c, part of the Reliable Datagram Sockets (RDS) protocol implementation. In every kernel before 2.6.36, that function copies data between user space and kernel space using addresses supplied by the calling process without properly validating them. By issuing crafted sendmsg and recvmsg system calls on an RDS socket, an unprivileged local user can read from and write to arbitrary kernel memory.

The fault class is improper input validation (CWE-20): the kernel trusts a user-controlled pointer that it should have range-checked against the process address space. The practical consequence is a clean, reliable path from any shell account to root. This is not remote code execution. An attacker already needs to be able to run code on the box, but the moment they can, they own the kernel. That combination: trivial reliability, full system compromise, and a published exploit, is why it carries a CVSS 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and sits on the CISA KEV list.

Why this CVE matters

RDS was never a niche concern here. On many distributions the rds module loads automatically the first time any process creates an RDS socket, so an attacker does not need RDS to be in use. they just need it to be loadable. A standard user account, a web-app process running as www-data, a compromised CI runner: any of these becomes a root shell. The original vsecurity advisory shipped a working linux-rds-exploit.c, and a copy lives on Exploit-DB (entry 44677), so weaponization is a download, not a research project.

CISA added CVE-2010-3904 to the Known Exploited Vulnerabilities catalog on 2023-05-12, thirteen years after disclosure: which tells you it is still being found and abused on long-lived, under-patched fleets. Federal agencies had until 2023-06-02 to remediate. If you run anything on a kernel older than 2.6.36 (think frozen appliances, embedded gateways, ancient RHEL 5 / 6 hosts), assume it is a target.

Check whether you are affected

This is a kernel bug, so the only version that matters is the running kernel, not a userland package. Read it directly:

# Running kernel version (anything before 2.6.36 upstream is vulnerable;
# distro backports may carry a fixed 2.6.18/2.6.27/2.6.32 build instead)
uname -r

# Is the vulnerable RDS module loaded right now?
lsmod | grep rds

# Can an unprivileged user auto-load it? (if this succeeds, you are exposed)
modprobe -n -v rds

If uname -r shows a kernel older than 2.6.36 and your distribution has not backported the fix, the flaw applies. Match the running build against your distribution's patched kernel package below.

How to fix CVE-2010-3904

The fix is upstream Linux kernel 2.6.36, delivered by commit 799c10559d60f159ab2232203f222f18fa3c4a5f, which adds the missing user-address validation to rds_page_copy_user. You almost never install that exact upstream version in practice. Instead you install your distribution's patched kernel package. the vendors backported the identical fix into the older kernels they ship, and then reboot. A kernel patch does nothing until you boot into it.

Ubuntu / Debian

Ubuntu's fix shipped as USN-1000-1. Update the kernel meta-package for your flavor (linux-image-generic, linux-image-server, or linux-image-virtual depending on the install) and reboot:

sudo apt-get update
sudo apt-get install --only-upgrade linux-image-generic   # or -server / -virtual
sudo reboot
# after reboot, confirm the running kernel advanced
uname -r

RHEL / CentOS

Red Hat fixed it in RHSA-2010:0792 (with RHSA-2010:0842 following). The kernel package is simply kernel:

sudo yum update kernel        # RHEL/CentOS 5/6 (yum); use 'dnf update kernel' on 8+
sudo reboot
uname -r                       # must show the patched kernel-... build, not the old one
rpm -q --changelog kernel | grep -i CVE-2010-3904   # confirm the errata is present

SUSE / openSUSE

SUSE addressed it across SUSE-SA:2010:053 and follow-ups:

sudo zypper refresh
sudo zypper update -t package kernel-default   # adjust flavor: -default / -xen / -pae
sudo reboot
uname -r

Interim mitigation: blacklist the RDS module

If you cannot reboot into a patched kernel immediately, you can take the attack surface away by preventing the vulnerable rds module from loading. This is the official-style workaround for the period before the kernel is patched: it removes the exploitable code path without touching the kernel:

# Stop rds from being auto-loaded by socket creation
echo 'install rds /bin/true' | sudo tee /etc/modprobe.d/disable-rds.conf

# Unload it now if it is already resident and nothing depends on it
sudo modprobe -r rds 2>/dev/null || true

# Verify it is gone and cannot be auto-loaded
lsmod | grep rds            # should print nothing
modprobe -n -v rds          # should resolve to /bin/true

Blacklisting is a stop-gap, not a cure: it only protects you while the config stays in place and the module is not already loaded by something with privilege. Reboot into the patched kernel as soon as your change window allows, then remove the blacklist if you actually need RDS.

Verify the fix landed

Because this is a kernel fix, verification means confirming the running kernel is patched, not just that a package is installed. Run after the reboot:

# 1. The running kernel is the patched build
uname -r

# 2. The errata that carries the CVE-2010-3904 fix is present (RPM distros)
rpm -q --changelog kernel | grep -i 3904

# 3. The RDS attack path is either patched or blacklisted
modprobe -n -v rds

# 4. Re-run your authenticated scanner and confirm CVE-2010-3904 no longer flags

If uname -r still shows the pre-patch kernel after the update, you booted the old build, check your bootloader default and reboot again. On hosts that were exposed for a long window, treat any local-account compromise as potential root compromise: review auth and sudo logs, look for unexpected accounts or SUID binaries, and rotate credentials that lived on the box.

Frequently asked questions

Which Linux kernel version fixes CVE-2010-3904?

The flaw is fixed in upstream Linux kernel 2.6.36 by commit 799c10559d60f159ab2232203f222f18fa3c4a5f, which adds the missing rds_page_copy_user address validation. Enterprise distributions backported the same fix into their 2.6.18 / 2.6.27 / 2.6.32-era kernels: Red Hat via RHSA-2010:0792 and RHSA-2010:0842, Ubuntu via USN-1000-1, and SUSE via SUSE-SA:2010:053. Install your distribution's patched kernel package and reboot rather than chasing the exact upstream version number.

Can CVE-2010-3904 be exploited remotely?

No. This is a local privilege-escalation bug, not remote code execution. An attacker needs an existing local account (or a foothold from another flaw) and must be able to open an RDS socket and issue crafted sendmsg/recvmsg calls. The payoff is root, which is why CISA lists it as actively exploited despite being local-only.

I do not use RDS. Am I still affected by CVE-2010-3904?

Probably yes. If the rds kernel module can be auto-loaded, an unprivileged user triggers it just by creating an RDS socket, so you are exposed even when no application uses RDS. As an interim mitigation before you reboot into the patched kernel, blacklist the module with install rds /bin/true in /etc/modprobe.d/ and confirm with lsmod | grep rds. Patching the kernel is still the durable fix.

How do I confirm the fix is live after patching?

Run uname -r and confirm it shows the patched kernel build. not just the package database, because a new kernel only takes effect after a reboot. On RPM systems, rpm -q --changelog kernel | grep 3904 confirms the errata is present. Then re-run an authenticated vulnerability scan and confirm CVE-2010-3904 no longer flags.

References

This guide was assembled from the MITRE CVE record, the distribution advisories (RHSA-2010:0792, USN-1000-1, SUSE-SA:2010:053), the upstream kernel changelog for 2.6.36, and the CISA KEV catalog entry. Always confirm against your distribution's advisory before applying changes in production.

Other defects in the same area that deserve attention during this patch cycle:

People also ask

Which Linux kernel version fixes CVE-2010-3904?

Upstream Linux kernel 2.6.36 (commit 799c1055) carries the fix. Distributions backported it: Red Hat RHSA-2010:0792, Ubuntu USN-1000-1, SUSE-SA:2010:053. Install your distro's patched kernel package and reboot.

Can CVE-2010-3904 be exploited remotely?

No. It is a local privilege escalation. An attacker needs an existing local account and the ability to open an RDS socket and call sendmsg/recvmsg, after which they gain root.

I do not use RDS. Am I still affected?

Likely yes, the rds module can auto-load when any user creates an RDS socket. Blacklist it with install rds /bin/true as an interim mitigation, then reboot into the patched kernel.