Denial of Fuzzing: Rust-Safe Code Triggers Kernel Crashes in Windows

A Windows kernel change meant to improve safety instead enabled a reliable blue screen. 

Check Point researchers found that malformed EMF/EMF+ metafiles can crash fully patched Windows 11 systems by triggering a panic in a new Rust-based GDI region component. 

“This issue is likely caused by the v88 and v95 loop variables incrementing beyond valid limits without proper safeguards,” said Check Point researchers.

The risk

For enterprises, the risk is disruption at scale rather than code execution: a crafted metafile rendered in user context can blue-screen endpoints across a domain, producing downtime, data loss, and recovery costs. 

Although Microsoft classified the issue as moderate severity and addressed it via an update, Check Point’s work shows a practical enterprise-wide denial-of-service (DoS) proof-of-concept (PoC) that security teams should treat as operationally significant.

What Check Point found

The researchers’ fuzzing of Windows graphics via tiny EMF/EMF+ seeds surfaced a recurring SYSTEM_SERVICE_EXCEPTION in win32kbase_rs.sys, the Rust implementation of GDI regions.

The crash occurs when path-to-region conversion (for example, after EmfPlusDrawBeziers) hits an out-of-bounds index, which Rust correctly detects and then panics — propagating to a system bugcheck.

Check Point verified that a malformed EMF+ record rendered through Graphics::FromImage() and DrawImage() in a standard user session could consistently trigger the kernel panic on Windows 11 24H2 builds prior to the fix from Microsoft. 

How the vulnerability works

In the vulnerable builds, region creation (region_from_path_mut) walked edge lists derived from widened or flattened paths. 

Certain mutated Bezier inputs and pen attributes produced edge blocks that drove an index past bounds.

Rust’s panic_bounds_check() caught it, but the resulting panic crashed the operating system (OS) instead of failing gracefully in kernel mode.

The Check Point team published a proof-of-concept showing the crash can be triggered from a low-integrity, non-admin context by rendering a malicious metafile. 

This is a denial-of-service scenario—no evidence of remote code execution—but it is low complexity and high impact for availability. Microsoft has already released a patch for the issue.

Mitigations

• Patch: Update all Windows 11 24H2 endpoints to OS Build 26100.4202 or later and confirm that any skipped preview updates are covered by the latest cumulative release.
• Block risky content: Block or remove EMF/EMF+ files in email, web, and collaboration tools, treating them as executable-like content and using safer formats like PNG or JPEG instead.
• Harden rendering paths: Open untrusted attachments only in Protected View or sandboxed viewers, and disable automatic metafile previews in email clients where possible.
• Detect and respond: Monitor for BugCheck 0x3B errors linked to metafile activity and investigate unusual spikes in win32k crash telemetry across multiple systems.
• User training: Educate users to be cautious with unexpected image or graphic file attachments and shared content.

When kernel panic paths can be triggered by user-controlled input, they effectively become reliable denial-of-service (DoS) vectors. 

Organizations should pair memory-safe rewrites with strong error-handling and thorough fuzz testing — especially for graphics parsers — before enabling new features at scale. 

Remember, availability is a core element of security: even “safe” crashes can cause real-world outages if attackers can trigger them repeatedly. 

Patch quickly, minimize risky file surfaces, and design infrastructure for cyber resilience.

To truly minimize the impact of vulnerabilities, organizations must go beyond just patching and adopt a zero-trust approach.