## https://sploitus.com/exploit?id=04E714B6-AAB4-5BB1-A856-A74CD8B3C97C
# CVE-2026-2636: CLFS.sys Unrecoverable State Leading to BSoD
## Overview
**CVE-2026-2636** is a vulnerability in the Windows Common Log File System (CLFS) driver (`CLFS.sys`). An unprivileged user can trigger an unrecoverable system state by calling the `ReadFile` API on a handle opened via `CreateLogFile`. This results in a Blue Screen of Death (BSoD), leading to a denial of service (DoS).
**CVSS Vector:** (Awaiting Official Assignment)
**Impact:** Denial of Service (System Crash)
**Discovered:** 2025
**Patch Release:** September 2025 Cumulative Update
---
## Affected Systems
| Version | Status |
|---------|--------|
| Windows 11 23H2 and earlier | ? Vulnerable |
| Windows 11 2024 LTSC (pre-September 2025) | ? Vulnerable |
| Windows Server 2025 (pre-September 2025) | ? Vulnerable |
| Windows 11 2024 LTSC (with Sep 2025 update) | ? Patched |
| Windows Server 2025 (with Sep 2025 update) | ? Patched |
| Windows 25H2 (released September 2025) | ? Patched |
---
## Technical Deep Dive
### Root Cause Analysis
The vulnerability stems from **CWE-159: Improper Handling of Invalid Use of Special Elements**. Specifically, the CLFS driver fails to properly validate the combination of flags in the I/O Request Packet (IRP) associated with a read operation on a CLFS log file.
### IRP Flag Behavior
When a read operation is initiated via `ReadFile` on a handle created by `CreateLogFile`, the system generates an IRP with specific flags:
| Flag | Value | Description |
|------|-------|-------------|
| `IRP_PAGING_IO` | `0x02` | Indicates I/O relates to memory paging (paging file or memory-mapped files) |
| `IRP_INPUT_OPERATION` | *Varies* | Indicates the I/O operation involves input data transfer |
**Critical Insight:** For correct function behavior, **at least one** of these flags should be enabled. In the PoC scenario, both are disabled, which leads to the incorrect handling path that triggers the BSoD.
### Why This Matters
While the CLFS subsystem has been a source of past vulnerabilities (often related to crafted `.blf` files), this issue is unique because:
- ? It does **not** require a maliciously crafted log file
- ? It relies solely on an unexpected sequence of legitimate Windows API calls
- ? It highlights a logical flaw in how the driver handles I/O requests from user mode
- ? It can be triggered by an **unprivileged user**
---
## Proof of Concept (PoC)
### Code Analysis
The PoC is deliberately minimal and consists of only two main API calls, demonstrating the simplicity of the trigger: