A Rust "fail" in the Windows Kernel - Click Bait? Read on to find out!

Just saw this: Check Point finds Windows kernel vunerability: Rust programming language fail - NotebookCheck.net News

The "Fail" in question is that, seemingly, that Rust code in the kernel panicked and took down the kernel, certainly an issue, but literally the next few issues reported in the original blog post were all remote code execution in non-Rust code, and I know which I'd prefer!

It will be interesting to see if these sorts of security click-bait stories develop in the future, if Rust is starting to prevent actually bad flaws.

7 Likes

I mean, either of the publications – the article you’ve linked, but also (perhaps more importantly) the original one from the company that reported the bug – is pretty hopelessly bad. The article you link adds light fluff, ads, and some dose of accidental misinformation to the story, as any good second-hand report would do. TBH, it’s pretty wild to recommend the book “The Rust Programming Language” exclusively by means of providing a link to the amazon.com page … an affiliate link, of course.

Rust is a programming language that emerged in 2006, with its first stable release in 2015 (learn about Rust in this book on Amazon). Like Ada, which emerged in 1977, Rust was designed to help minimize safety issues, including memory leaks due to poorly written code, which can occur more frequently in C++.

yes, minimizing memory leaks, the prime example of Rust’s memory safety features


But I find the publication that all this appears to originate from more interesting anyway… Microsoft Vulnerabilities Exposed by Check Point Research - Check Point Blog

This is pretty weird, because it cannot possibly have been written by someone that understands Rust. Or… well… I guess understanding the programming language isn’t really relevant to finding security flaws in closed-source software? :thinking: Either that, or they have different people write & proof-read these things than actually discover the issues.

I’ll quote the whole relevant section for reference

1. Vulnerability in Rust-Based Windows Kernel Component — System Crash Risk

Check Point Research uncovered what is probably the first-ever publicly disclosed security flaw in a Rust-based component of the Windows kernel—Microsoft’s foundational operating system layer. This vulnerability can cause a total system crash, forcing a hard reboot and instantly knocking users offline.

Rust is widely praised for its ability to prevent memory bugs that have long challenged software security. Its introduction into Windows aimed to enhance system safety. In this case, the vulnerability emerged because Rust detected an underlying issue—but instead of containing the problem gracefully, it triggered a system-wide failure.

For organizations with large or remote workforces, the risk is significant: attackers could exploit this flaw to simultaneously crash numerous computers across an enterprise, resulting in widespread disruption and costly downtime.

This discovery highlights that even with advanced security technologies like Rust, continuous vigilance and proactive patching are essential to maintaining system integrity in a complex software environment.

For context, I’m completely unable to find any additional information on the issue in question. For all I can tell, it was possibly considered so unimportant, it didn’t even get a CVE? Or maybe my search skills are too bad, but I honestly tried (and they certainly didn’t link anything). They do a remarkably bad job in describing what the actual vulnerability was like… I can only try to deduce that they’re trying to tell us that it’s an issue where one can cause a crash remotely since otherwise even the remark about “simultaneously crash[ing] numerous computers across an enterprise” would be nonsensical…

…but if this is really all that’s published on the issue, then almost nothing is published on the issue at all. Like… what does this say? A “vulnerability [that can] cause a total system crash, forcing a hard reboot” which came about because some “underlying issue” happened. Mind being any more vague? Arguably this cannot possibly be the “first-ever publicly disclosed security flaw in a Rust-based component of the Windows kernel” because this publication wouldn’t even qualify of “public disclosure” of anything!


So here’s why I don’t believe the author of this text could really be “understanding Rust”:

“In this case, the vulnerability emerged because Rust detected an underlying issue—but instead of containing the problem gracefully, it triggered a system-wide failure.”

Is the first part to this. Rust doesn’t actually “do” anything. It’s merely a programming language; some Rust code in some library can have detected some “underlying issue” and crashed, presumably via some error value or (perhaps more likely) through panicking… which… one can even turn – easily – into valid (and known) criticism on the language: it doesn’t make it particularly easy to contain all possibility for panicking. Whether or not this was relevant here, who knows?… maybe the system went down, because some “underlying issue“ in question was actually so severe, that there wasn’t any safe way of containing the problem gracefully. If only they had at least been so generous as to mention what kind of kernel component was affected. :man_shrugging:t2:

And then the second part is how in the end they call Rust “advanced security technolog[y]”. I don’t even know where to begin … actually … re-checking the article, it really reads as if “Rust” was some kind of security system component added on top of whatever other stuff… I’ll take back part of my criticism of the Notebookcheck one for getting this point straight.

And the article also has such a misleading introduction…

On Tuesday, August 12th, Microsoft released the final patches for six newly discovered Windows vulnerabilities identified by Check Point Research, including one rated as critical. These vulnerabilities could crash entire systems or allow attackers to run malicious code, posing real risks to business operations.

…

Breaking Down the Vulnerabilities

Check Point Research identified six vulnerabilities in Microsoft Windows, ranging from critical to moderate severity. In this section, we’ll focus on the three most significant flaws, explaining their potential impact and why they matter—before briefly summarizing the remaining ones.

1. Vulnerability in Rust-Based Windows Kernel Component — System Crash Risk

Check Point Research uncovered what[…] [we quoted this above]

2. Memory Corruption Vulnerabilities Enabling Arbitrary Code Execution

Among the remaining vulnerabilities, two are especially concerning due to their exploitability […]

Both vulnerabilities, tracked as CVE-2025-30388 and CVE-2025-53766, allow attackers to execute arbitrary code on the affected system, effectively giving them the ability to run any malicious software they choose. […]

3. Additional Memory Corruption and Information Disclosure Vulnerabilities

The remaining three vulnerabilities also involve memory corruption, but with a different twist: they lead to information disclosure.

Typically, information leaks are less immediately dangerous because an attacker would need a way to obtain the data leaked on a local system. […]

So quiz question: Which one was the “one [vulnerability] rated as critical”? Notebookcheck did get it… wrong.

Check Point has uncovered critical flaws in Microsoft Windows, including a Rust-based kernel vulnerability that could let attackers crash systems.
…
Check Point has found flaws in the Microsoft Windows operating system this month, including a critical one that allows attackers to crash systems.

One could certainly think they did start with the critical one. But reading (a lot!) more carefully reveals, they didn’t. Let’s more carefully (I noticed this on the 4th read or so only myself…) including a sentence I skipped in my first quoting of this paragraph:

2. Memory Corruption Vulnerabilities Enabling Arbitrary Code Execution

Among the remaining vulnerabilities, two are especially concerning due to their exploitability, one of which is classified as critical and was patched Tuesday, August 12th.

I personally only really noticed this after being in disbelief that the Rust vulnerability really ought to be the one critical issue, and after then clicking the CVE / MSRC links to have one of them appear marked as “Critical” severity, and after then doing a full-text search of the word “critical” on the post to understand the connections & what’s actually being claimed here.

I’m not even 100% convinced if the “three most significant flaws” that they allude to are supposed to mean the first three, or the three that got a CVE they linked. Everything strongly sounds like they intend to say it’s the first three, but I can’t really find where it would actually clearly say that.

15 Likes

Yep, they moved past click bait and are into rage bait territory at this point! Certainly it's not doing a good job at selling me on their security services.

It's funny though, as if we take the original post at their word, this is a pretty interesting story still as it would be one of the first instances of Rust actively preventing a (much worse, at least) security issue.

Or maybe not, impossible to tell with how little information it has.

1 Like

You can search for "check point research" on Microsoft's CVE Acknowledgements - Security Update Guide - Microsoft. The only one that turns up that is dated August 12 is the CVE-2025-53766.

So, failing to find it easily, I went through every Windows CVE published on August 12, and I only found three that could potentially be the kernel crash:

  1. CVE-2025-50172 (DirectX resource leak DoS)
  2. CVE-2025-53151 (Local kernel crash "use after free")
  3. CVE-2025-53716 (LSASS DoS "null pointer derefence")

It isn't really clear based on the information provided (which is almost nothing) or even the acknowledgments whether any of these are the crash discovered by Check Point Research. But this is the best list I was able to come up with for potential candidates.

Yeah, it's probably this.

4 Likes

A resource leak (DirectX one) takes forever to crater the operating system. The kernel just keeps expanding the swap file until it runs out of disk space. But, I very highly doubt Microsoft rewrote the DirectX kernel driver in Rust. Maybe. Someday. Not now.

The user-after-free one doesn't match the description in the article (elevated privileges versus kernel panic).

LSASS is a service / not a kernel driver. It's not capable of triggering a kernel panic. That one is out.

Strongly agree.

The proposal regarding prevention of memory-related faults is that Rust addresses 70% of the causes of issues:

...in Rust, 70% of these security issues would most likely have been eliminated.

Why Rust for safe systems programming

It's no statement about Rust's leadership in memory safety if one of the other 30% is found:

At some point code must manage and access memory.

.NET uses assembly language in the runtime:
runtime/src/coreclr/runtime/amd64 at main · dotnet/runtime

.NET uses C++ in the garbage collector:
runtime/src/coreclr/gc at main · dotnet/runtime

.NET uses C for the native AOT:
runtime/src/native/minipal at main · dotnet/runtime

Rust uses LLVM which (unless/until rewritten in Rust) uses C and C++. Some Rust crates encapsulate unsafe code that operates with memory.

Any language's memory safety and management strategy cannot avoid the necessity of some software managing and accessing memory. The key is a hierarchy whereby memory operations are isolated to compilers/toolchain (e.g. Rust, and few others, if any), lower-levels, and crates/libraries. Rust and .NET, both recommended by CISA, are no different in this regard. The difference is that Rust does it without the performance overhead of a runtime, a JIT, and a garbage collector.

Rust is superior in memory safety to C and C++. That doesn't mean that in the software world, memory is never accessed. So, engineers that work on these isolated sections of code, must still be knowledgeable and careful.

Note the article of OP:

...This marks the first publicly disclosed Rust kernel exploit,...

The first one exposed is overflow. The source code accessed memory outside of the valid memory space. This is not a malloc/free scenario. This is one of the other 30%. The first exploit disclosed, does not relate to Rust's specialty (unless someone's not disclosing prior exploits of the category of the other 70%, extremely unlikely). This is a good sign, that Rust is working as intended.