I would say that Rust has a good story here. The simple form of this wouldn't compile. So you are generally presented two options:

1. Slap a reference count on it.

2. Use `unsafe` to promise the compiler that your code is right.

I would say that 1 is a pretty good habit to have. It may open you to memory leaks if you aren't careful but those are much less bad than a use-after-free or other memory management issues. And of course the fact that this was the route the patch took is a good sign. I think this is a pretty good default option.

Now if performance is a major issue you may consider going to 2, so it is impossible to say "Rust would have prevented this" because if it was originally written in Rust this may have been the route taken. But I think it is still very valuable to make that an explicit choice and obvious to reviewers and readers.

This is the answer I think. The correctness of your safe code is dependent on the diligence of the unsafe code except for the most simple cases. A kernel is going to have a pretty high unsafe to safe ratio compared to most usermode apps.

This really gets to the core of what I think Rust is about, you can add compiler checked constraints to your APIs that your C and C++ code can't. It's up to you to use them effectively. Rust's ability to keep your safe code safe is a measure of the language, but also your architecture. The buck has to stop somewhere for the language to prove safety, Rust lets you decide rather than the language itself.