My question is related to vulnerabilities that allow installing a Linux kernel-level rootkit (for example, to modify the execution flow inside the kernel; for return-oriented attacks; or to modify some structures in order to hide certain processes).

In the following site, I found a nice classification of the publicly-known Linux kernel vulnerabilities until now:


I was a bit surprised when I noticed that there were no (publicly known) vulnerabilities for code execution in 2011.

Does it mean that the rest of the vulnerabilities in that table (e.g., DoS, memory corruption, overflow) cannot be exploited for executing a kernel-level rootkit?

I have an ARM-based Android embedded system. The Linux kernel has this functionality disabled: "dynamic kernel modules", "/dev/kmem", "/dev/mem/", "ksplice". Also the system has a Secure BOOT process in place (e.g., the Linux kernel cannot access any boot files and this is enforced by hardware). Therefore, the only way I know to install a kernel-level rootkit (apart from hardware attacks) is by exploiting a bug in the kernel*.


2 Answers 2


Vulnerabilities in the kernel itself, whilst serious, are only part of the story for every day users.

The issue for "normal", "out of the box" installs are in fact vulnerabilities in processes running as root. Since these are trusted they can ask the kernel to do whatever they like - including inserting kernel modules or accessing /dev/kmem.

It is important to understand that, CPU-wise, root processes run as unprivileged processes as far as the CPU is concerned. On x86 we call this ring 3; on ARM processors the CPU modes are User, FIQ, IRQ, Supervisor, Abort and Undef, where User is the unprivileged level used for processes (all the other modes are in fact privileged ones). Executing processes in User mode cannot modify other processes or the kernel directly; they must ask the kernel first. However, as they are trusted, the kernel does not "say no". So for an ordinary setup, it is enough to compromise a process running as root.

Now, in your setup things are a little different - you've disabled module loading and access to /dev/kmem. To do any serious damage, you need to get your rootkit to execute in supervisor mode (ring 0/any modes that are not User) or be able to manipulate /dev/kmem. Since you cannot modify the boot entries either, this leaves the hardware level as the major threat vector (or ksplice. You mention that on SO; it is most definitely a risk because you allow patching a running kernel with code! kexec is another potential problem because you replace the kernel in place).

So in theory, what you have is significantly more secure.

Does it mean that the rest of vulnerabilities in that table (e.g., DoS, memory corruption, overflow) cannot be exploited for executing a kernel-level rootkit?

Well, to deal with the last bit first - you don't need to be able to exploit a vulnerability on a "normal" system because you can just insert a kernel module. However, in your case this is practically your only avenue; you would need to find a bug somewhere in the system that either lets you load code or otherwise can be exploited to control the kernel.

Now, on your zero bugs observation - as you say, there are zero known bugs in that time frame. That does not mean there are not bugs. Also, we should caveat this with:

  • Is this your distribution's kernel? Does it have patches not present in the vanilla kernel? These patches also add risk.
  • Does your kernel require extra third party code (graphics card drivers, virtualisation drivers)? If so, these also add risk.

Now, about those CVEs - yes, when they say no "code execution" that's what it means. The vulnerabilities present can corrupt memory and perform DoS but cannot actually run malicious code. Take a look at one of the code execution vulnerabilities:

...allow remote attackers to cause a denial of service (panic) or possibly execute arbitrary code...

So yes, as it stands there are no known code-execution vulnerabilities in the kernel at the time of writing Update in light of this answer I'm crossing that bit through - it's not clear from the site which entry represents the vanilla kernel and which represent vendor supplied kernels, or indeed what the difference is. Let me caveat that with in whatever definition of the kernel that was there were zero vulnerabilities, which is what I was trying to get at before with talk of vendor supplied patches/third-party code.

  • There are other ways you can get to ring 0, such as ACPI custom_method.
    – forest
    May 22, 2019 at 3:35

CVE data, published by NVD (cvedetails.com publishes data published by the National Vulnerability Database, nvd.nist.gov.), have some inconsistencies, especially product and version information are not reliable.

For example there are multiple product definitions for the linux kernel. Please see http://www.cvedetails.com/product-list/vendor_id-33/Linux.html for a list of related products. (And there may be even more vulnerabilities defined with some other vendor or product name)

So to be sure you should check vulnerabilities defined for other related products too. You should at least check http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 (There are some exploits related to vulnerabilities related to this product)

It is hard to be sure that you are not missing a vulnerability. cvedetails.com has product/vendor matching features that allow users to match related products but to be honest they are not popular.

(P.S: I am the owner of cvedetails.com)

  • Please fix cvedetails.com it seems to have very poor accuracy. - eg the page for microsoft word
    – Jasen
    Jan 24, 2023 at 21:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .