Denial of Fuzzing: Rust in the Windows Kernel

That's true, but really this kind of problem screams out for the approach taken in WUFFS. Have the programmer who is Wrangling Untrusted File Formats prove that what they wrote is correct as part of that exercise.

This is my experience as well: Writing parsers for complex file formats in Rust often leaves a few edge cases which might cause controlled panics. But controlled panics are essentially denial of service attacks. And panics have good logging, making them easy to debug. Plus, you can fuzz for them at scale easily, using tools like "cargo fuzz".

This is a substantial improvement over the status quo.

Tools like WUFFS may be more appropriate for low level parsing logic when you're not willing to risk controlled panics, however.

> A bug in Rust component that could have led to Windows kernel compromise

I don't think this bug could have led to a kernel compromise unless you count a DoS as a kernel compromise, which I'm a bit skeptical of. From the article:

> Notably, the system crash was triggered by this new kernel component designed to improve security, as suggested by the name of the panic_bounds_check() function referenced in the stack trace shown in Figure 2.

Later:

> When the region_from_path_mut() function converts a path into a region it represents the outline as a singly linked list of edge blocks. The program detects the out-of-bounds memory access via core::panicking::panic_bounds_check() and triggers a SYSTEM_SERVICE_EXCEPTION.

And from Microsoft's assessment of the bug:

> “the Rust code correctly catches an out-of-bounds array access and triggers a panic, resulting in a Blue Screen of Death (BSOD), as expected”

Furthermore, from the implementation of core::panicking::panic_bounds_check() [0]:

    #[lang = "panic_bounds_check"] // needed by codegen for panic on OOB array/slice access
    fn panic_bounds_check(index: usize, len: usize) -> ! { ... }

So you have an attempted OOB access, but since (safe) Rust guarantees OOB accesses will panic I don't think there's a path to escalate the DoS to a full kernel compromise short of an optimizer bug and/or the use of unsafe, for which there doesn't appear to be evidence for either.

[0]: https://doc.rust-lang.org/stable/src/core/panicking.rs.html