The general idea is that an exploitable remote code execution bug is some specific circumstances where the processor starts to execute whatever is in some wrong address which can be manipulated by an attacker.

If the bug is successfully exploited, the attacker arranges so that everything is just so that device runs "as if normal" but executes whatever code attacker decided to be executed; but if the bug is triggered accidentally or without a working exploit, then it attempts to execute something random and that results in a kernel panic.

So the way how "malware prevents a kernel panic" is that it's a successful exploit if and only if it manages to ensure that valid (but attacker-controlled) code runs and actually works, and if it instead results in a kernel panic, well, that's not a working malware, unless all the attacker wanted was a denial of service exploit.

A kernel panic is caused by some serious issue in either the kernel or the hardware. In itself, it's relatively "harmless": it just means the OS stops doing anything and you need to hard reboot the machine (such as by cutting power).

However, if the kernel panic is caused by a software bug (rather than something like a broken RAM stick), then the bug which causes the kernel panic might also be exploitable by malicious code to do things like arbitrary kernel level code execution. For example, if the problem is that the kernel somehow allows the user to change a piece of memory which the kernel interprets as a function pointer, then the result of carelessly changing that piece of memory will cause the kernel to jump into some part of memory that's not valid code, causing a kernel panic; however, a very clever attacker may pick a jump address which causes the kernel to keep executing without crashing but doing something which the developer of the kernel didn't intend. Maybe the attacker can cause the kernel to jump to a location in memory which the attacker has control over, which would mean that the attacker can run arbitrary code in kernel mode.

This stuff is all very complicated and very interesting, I recommend reading up on it if it interests you.

And no, the kernel can't really check if it's being manipulated. A checksum at startup wouldn't do it since these sorts of exploits don't tend to involve changing the kernel bytes on disk, but rather tricking the kernel into doing something it's not supposed to. There are various mechanisms to try to make bugs unexploitable (such as address space layout randomisation), but fundamentally, you can't perfectly protect against potential bugs.

Thanks! Yeah I really need to work on my low level security knowledge this stuff is fascinating when it isn't presented in the form of a crypto algorithim that is heirogylphics to me.