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.
