Aside: static analysis is a great initial effort but to really get confidence you should use techniques like sanitizers (MSan in this case) or valgrind. (This is general advice, not always applicable to kernels).
You should really use both, however they are only a tool: I don't have any numbers but I imagine Sanitizers have a good detection rate, but one should still write code defensively. There are too many horror stories, be they lethal or expensive, to be risky about memory.
Not a kernel developer: Can you test Kernel code with a sanitizer (if that sanitizer doesn't work in a compiled kernel) by compiling into and using the code as blob in userspace code with mocks (Or whatever, unless it's just utility that doesn't need anything other than an interface)?
I'm not sure what this means. You should not write your code any differently regardless of whether you used a sanitizer to help gain confidence in your implementation.
You should not use sanitizers in production (at least not the current generation).
> Can you test Kernel code with a sanitizer
In fact you can! Both UBSan [1] and ASan [2] are in use to root out bugs in linux.
Linux has support for kernel ASAN and I think UBSAN too. User mode linux is a also thing and does roughly what you described, and I think you can run it under valgrind too.
To be fair, UML runs at such a low level (raw syscalls rather than calls to, for instance, malloc and free) that it really limits what valgrind can tell you.
As far as I know Kostya he started by improving Helgrind as valgrind plugin in 2008: the first ThreadSanitizer (as project data-race-test) https://storage.googleapis.com/pub-tools-public-publication-... which was a harder problem than oob checks.
But it was still too slow, and they started with tsan and asan as clang plugin. Years later they ported it to gcc. gcc started then becoming more plugin friendly.
