No. The issue is that an assumption they make in the unsafe block does not actually always hold true. They changed the safe rust code to strenghten the (incorrect) assumption they made in the first place, because that is way easier than rearchitecting the unsafe part. I.e. if the unsafe part was somehow to be written safely, the mitigation they introduced now would not result in any difference in behaviour, it would be correct behaviour both before and after.

Tldr: the problem lies in the unsafe part

I'll admit, I haven't looked at the code. I would stand by my comment of the unsafe block being a start point.

Countering that however, what is the difference to just debugging effectively? Not sure. I suppose it's down to the people that identified it and fixed it at the end of the day to say if there was any benefit.

It certainly does. It's way simpler to keep up all invariants and to review the few percent lines of code in unsafe blocks than making sure that the 30 million lines of code are free of undefined behavior.

Is some part of the code it battle tested of course it's complete unreasonable to rewrite it in any language, but if you have to do a major rewrite anyway or write a new component you should definitely use a memory safe language. And no it doesn't matter that there is an unsafe escape hatch because it's literally impossible to write low level kernel stuff or FFI to other languages without unsafe because Rust can't uphold/guarantee the invariants of the hardware itself or the behavior of other languages.

thread fl2_worker_thread panicked: called Result::unwrap() on an Err value

Not sure if that's a fair metric yet.

You go ahead and write an OS kernel in C# then.

You say that. But the CVE is a memory corruption bug.