[wazari972]

> To load the rootkit into kernel space, it is necessary to approximately match the kernel version used for compiling; it does not have to be strictly the same.

>> vermagic=2.6.32-696.23.1.el6.x86_64 SMP mod_unload modversions

do you know why they say "approximately match"? I thought it had to match exactly so that the kernel accepts to load the module

[chr15p]

A kernel module doesn't have to match the kernel version, it has to be able to resolve all the symbols (function calls, variables etc) it uses into valid symbols supplied by the kernel you are loading on.

The greater the difference between the kernel version you compiled for, and the kernel version you are trying to load it on, the greater the chance something you are relying on changed and the module loader cant resolve all the symbols and so it fails.

So saying a kmod has to match the kernel version is good practice but the reality is not quite as strict.

Red Hat has a list of "white listed" symbols that they try to maintain across a major version of RHEL so if your kmod only relies on them and nothing else then it should load on any kernel version within that release. But that's a Red Hat thing, not a Linux kernel thing.

[xyzzy123]

Perhaps also worth noting that rootkits don't have to follow the usual rules; you don't have to rely on the kernel linker if you don't want to.

(Tradeoff of runtime DIY symbol resolution / code grovelling being it's more work, and more likely to be crashy).

As a rootkit author you have considerably more flexibility than most module authors who are constrained by "sanity", maintainability, accepted practice and licensing terms.

[yjftsjthsd-h]

I don't know the exact rules, but note that this is targeting RHEL6 and Red Hat makes a deliberate effort to preserve kernel ABI compatibility so it is probably a lot easier than on most Linux distributions.