CVE-2013-6282 Fix: ARM Kernel Bounds Check Patch
Treat any modern system flagging CVE-2013-6282 as a reporting problem, not a live hole. The CVE-2013-6282 fix has been upstream in the ARM Linux kernel for over a decade, and it shipped in every maintained distro kernel once the pre-3.5.5 trees got patched. The real bug was weak bounds checking in the get_user and put_user helpers on ARM, which let unprivileged code read and write arbitrary kernel memory. So if a scanner still points at it, read the kernel version and source on the box before you trust the label.
Last updated: 2026-07-21
What is CVE-2013-6282?
CVE-2013-6282 is a flaw in how the ARM Linux kernel validated addresses passed to get_user and put_user. Those two helpers copy a single value between user space and kernel space. On ARM v6k and v7, the access check was missing or wrong, so a user-supplied pointer into kernel memory sailed straight through.
That turns two tiny copy routines into an arbitrary read and write primitive. An unprivileged process could hand the kernel a kernel address and get back kernel data, or overwrite it. From there, privilege escalation is straightforward.
Scanners still flag it because the CVE record never expires. If your fleet includes ancient Android builds or a frozen embedded kernel, the flag may be real. On a current server, however, it almost never is.
Where the bounds check fails
The real problem is that get_user and put_user trusted the address they were given. Their whole job on ARM is to copy one word to or from a user pointer while catching faults. To do that safely, they must first prove the pointer lives in user space, below the kernel boundary.
On the affected ARM builds that check let certain addresses through. Here is what happens next. A local process calls a syscall that funnels a controlled pointer into one of these helpers. The pointer aims at kernel memory instead of the process's own pages, so the helper reads or writes there and reports success.
Repeat that in a loop and you can map out kernel structures, then flip the bytes that decide who is root. No memory corruption chain, no heap grooming. Just a bounds check that said yes when it should have said no.
Where this sits among kernel exploits
A kernel exploit is code that abuses a bug in the core of the operating system to do something the core was supposed to forbid. The kernel controls hardware and enforces security for every process, so a flaw there can hand an attacker higher rights or arbitrary code if left unpatched. Three real cases mark the range: CVE-2024-1086, CVE-2016-0728, and CVE-2013-6282 itself.
Most kernel exploits fall into three buckets, and CVE-2013-6282 is the tidiest of them. It hands the attacker a direct read/write primitive with no corruption gymnastics at all.
| Bug class | What goes wrong | Example CVE | What the fix does |
|---|---|---|---|
| Bad input validation | Kernel trusts a user pointer or value | CVE-2013-6282 | Add the missing bounds check |
| Use-after-free | Code touches memory after it was freed | CVE-2016-0728 | Fix object lifetime, refcounts |
| Memory corruption | Overflow or double-free in a subsystem | CVE-2024-1086 | Patch the vulnerable path |
CVE-2013-6282 is the concrete case where kernel memory access led straight to root on Android builds. The other two need more work to turn a crash into control. All three end the same way if you skip the patch.
The affected kernel versions and devices
Anything on ARM v6k or v7 running a kernel below the fixed points. Upstream landed the fix in the 3.2.54, 3.4.12, and 3.5.5 stable trees and everything after them. If your ARM kernel predates the branch it sits on, assume it is exposed.
In practice the damage was on Android. During late 2013 the bug got folded into root tools and in-the-wild exploits aimed at phones and tablets that shipped old vendor kernels and rarely updated. An upstream patch means nothing if the device maker never ships it, and that is the whole story of Android kernel security from that era.
Desktop and server distros pulled the fix into their stable kernels quickly. The long tail of pain sat in locked-down handsets. Data-center Linux had already moved on.
The real severity, then and now
Severe in isolation, minor in reality today. A local unprivileged process reading and writing arbitrary kernel memory is about as bad as a local bug gets, because it hands over full root with no further tricks. On an unpatched ARM device in 2013 you would triage this as urgent.
The catch is the word local. This is not a remote hole. An attacker already needs to run code on the box, so it is an escalation step, not an entry point. That still matters on multi-user systems and on any device where you run untrusted apps.
For triage now, the real severity is whatever your scanner's stale label does to your compliance report. Confirm the kernel is fixed and downgrade the finding. Do not schedule an emergency window for a bug patched before some of your servers were racked.
How the write turns into root
The read/write primitive is the whole ballgame. Once a local user can write any kernel address, they walk to the structure that holds their process credentials and rewrite it. On Linux that is the cred struct, which stores the user and group IDs the kernel checks on every permission decision.
Flip those fields to zero and the kernel now believes the process is root. From there it can run arbitrary commands, load modules, or disable the very controls meant to stop it. No password, no sudo, no extra bug.
This is why "arbitrary kernel memory access" and "unprivileged user gets root" describe the same event. The bounds-check flaw gave the write, the write gave the credentials, and everything downstream follows from there.
How do you apply the CVE-2013-6282 fix?
Update to a kernel at or past the fixed stable version and reboot into it. There is no config toggle and no runtime mitigation to fiddle with. The fix is a source change that adds the missing address check in the ARM get_user/put_user path, so you need a kernel that carries it.
On a normal distro, run this first:
apt update && apt full-upgradeon Debian or Ubuntu, ordnf upgrade kernelon Fedora and RHEL.- Reboot, because a running kernel keeps running until you replace it. See our guide on scheduling kernel updates so it becomes routine you never think about.
- If a reboot window is hard, read upgrading the kernel without a reboot before you assume live patching covers an old CVE like this one.
For an embedded or vendor ARM kernel with no upstream stable branch, you backport the commit yourself. Pull the patch that adds the bounds check into get_user/put_user, rebuild, and flash. That is the only path once the vendor abandons the device. The official record lives in the CVE-2013-6282 entry at NVD.
How do you confirm your system is actually patched?
Do not stop at the kernel version string. A distro backports fixes into a kernel whose number looks older than the upstream fix, so uname -r alone lies both ways. Check the version, then confirm the patch is really in the tree.
Run these in order:
uname -rfor the running kernel andarchto confirm you are even on ARM. On x86_64 this CVE does not apply, full stop.apt changelog linux-image-$(uname -r) 2>/dev/null | grep -i 6282on Debian or Ubuntu. If the changelog names the CVE as fixed, you are done.- If you build your own kernel,
grep -n "get_user" arch/arm/lib/getuser.Sand read the address check in the source. That tells you the bound is present, not assumed.
The point is to end on evidence. A version number is a claim; the changelog entry or the source line is proof, and proof is what closes the ticket.
Fix status on Ubuntu and Debian
Fixed and released everywhere still supported, years ago. Both distros track this CVE in their security trackers, and both marked their kernel packages patched once the stable backports landed. If you run a supported Ubuntu or Debian release and keep the kernel current, you carry the fix by default.
The only Ubuntu or Debian systems that could still be exposed are ones stuck on an end-of-life kernel with security updates switched off. That is a maintenance failure; the vulnerability itself closed years ago. Check the distro's security tracker for the exact fixed package version tied to your release, then compare it to what dpkg -l | grep linux-image reports installed.
If the tracker shows the CVE resolved and your installed package meets or beats the fixed version, the scanner finding is noise.
The real-world exploit and global impact
Real exploitation happened, but it was an Android story. Through October and November 2013 the bug was weaponized into root utilities and malware targeting phones and tablets on old vendor kernels. The scale of it came down to device-update policies, because the upstream fix already existed.
Patch availability was never the bottleneck. Upstream had fixed kernels out in the stable branches, and mainstream distros pull kernel fixes fast. As a rough gauge, the upstream kernel team ships patches within 24 to 48 hours of a critical vulnerability being confirmed. The lag was vendors who never shipped what upstream had ready.
Today the exploit status is historical. The bug is closed on any maintained system. What lingers is orphaned hardware that stopped getting updates, which is a device-lifecycle problem. The answer there is to retire the handset and replace it, since re-patching a decade-old kernel buys you nothing.
Is this related to the XPS13 brightness or other device bugs?
No. People sometimes land here after searching ARM kernel bugs and confuse this with the laptop brightness-control regression seen on Dell XPS 13 machines. That one is an unrelated driver and ACPI issue about backlight controls misbehaving. It is not a security flaw, and it shares nothing with CVE-2013-6282 beyond the words "kernel bug."
Mixing them up wastes an afternoon. One is an arbitrary-memory security hole on ARM handsets; the other is a display annoyance on x86 laptops. Different subsystem, different architecture, different fix. If your scanner or a forum thread ties them together, ignore the connection.
Where this fits in kernel vulnerability patterns
CVE-2013-6282 is the oldest pattern in the book: code trusting input it should have checked. The get_user bounds miss from 2013 and the netfilter corruption behind CVE-2024-1086 rhyme, only the subsystem changed. That same failure surfaces in fresh CVEs every year.
Third-party modules and vendor drivers make it worse, because they add code the upstream reviewers never saw. Expect null dereferences, races, and weak input checks in Wi-Fi and GPU blobs long before they reach mainline. The habit that protects you across all of them is dull and repeatable: check uname -r, then read the changelog or the source, then trust that.
Keep kernels current, treat vendor blobs as suspect, and confirm each fix in the changelog before you close the ticket. If you want to shrink the driver attack surface directly, start with safely blacklisting kernel modules. The bug class stays old. What changes is whether you bother to check.
FAQ
Does CVE-2013-6282 affect x86 or ARM64 servers?
No. The flaw sits in the 32-bit ARM v6k and v7 get_user/put_user code, nowhere else. If arch prints x86_64 or aarch64, this CVE cannot touch you, and any finding against it is a false positive to close on sight.
Can I mitigate it without updating the kernel?
Not really. No sysctl or boot flag adds the missing bounds check, so the running kernel has to carry the patched code. On an unfixable vendor device that leaves two options: backport the commit and rebuild it yourself, or retire the hardware.
Why does my scanner still report it on a fully updated system?
Usually the scanner matches on a kernel version string and misses the distro backport, because distros fix bugs without bumping the upstream number. Check the package changelog for the CVE, or read the source, and once the fix shows up, mark the finding resolved.
Is CVE-2013-6282 exploitable remotely?
No. Abusing the read/write needs local code execution first, so it raises privileges once an attacker is already inside. It still counts on any box where untrusted users or apps share one kernel.
How is this different from CVE-2024-1086?
Different bug class and architecture. CVE-2013-6282 is a bad-input-validation flaw on ARM. CVE-2024-1086 is a memory-corruption bug in netfilter, affecting kernels between 5.14 and 6.6.14, rated 7.8, and it takes more exploit work to reach root. They share only the outcome when left unpatched.
