Come on, managing memory in C isn't that hard. Yes, there are constant failures because many times people don't have a proper foundation in C memory management before they're allowed near the github commit bit. That's an organizational issue, not a language issue.
Rust does eliminate the issue, because it forces people to go through that foundational learning or their code won't actually compile! But C is also fine, if you know what you're doing.
"C is fine if you know what you're doing" is the "trust me, bro" approach to software engineering. Even experienced "C kernel wizards" make stupid mistakes. Also, nobody actually knows what a pointer is, not even the wizards; we keep learning new things about them every time someone finds a combination of optimizations that cause miscompiles[0]. For something as security-critical as an OS kernel, the correct approach is to have automatic verification - i.e. code can't stab you in the back if it can't compile.
See, I'm coming from the perspective that people who work with Language X have learned where all the dark corners of Language X are. Would you expect anything else? C does not have more dark corners than Python, Ruby, PHP, LISP, Rust, etc. Part of being an expert is knowing the language you're working with, and knowing the limits of your tools. When you update GCC and they add some bonkers optimization strategy that introduces new undefined behavior, you should know about that.
Even experienced "Rust kernel wizards" will make mistakes. You'll see.
Rust does eliminate the issue, because it forces people to go through that foundational learning or their code won't actually compile! But C is also fine, if you know what you're doing.