Using ReadFile with Handle of Opened .blf Log File Produces an Unrecoverable State in CLFS.sys Causing a BSoD

Using ReadFile with Handle of Opened .blf Log File Produces an Unrecoverable State in CLFS.sys Causing a BSoD

by
with no comment
BSoDCLFSDriverexploitationPoCwinapiwinapiWinDBGwindows

Original text by Ricardo Narvaja

PoC exploit https://github.com/oxfemale/CVE-2026-2636_PoC

Introduction

While researching the Common Log File System (CLFS) to analyze a published vulnerability, I achieved remote code execution (RCE). However, after modifying certain values in a proof of concept (PoC), I observed that it triggered a non‑exploitable blue screen of death (BSoD) on the target system. Consequently, I am reporting this issue. This document helps the reader understand the BSoD behavior and provides guidance on how the issue can be reproduced in a controlled research environment.

Vulnerability Details

This vulnerability is caused by CWE‑159: Improper Handling of Invalid Use of Special Elements, which leads to an unrecoverable inconsistency in the CLFS.sys driver. This condition forces a call to the KeBugCheckEx function, allowing an unprivileged user to trigger a system crash. This document uses CLFS.sys version 10.0.22621.5037 as an example. Microsoft silently fixed this vulnerability in the September 2025 cumulative update for Windows 11 2024 LTSC and Windows Server 2025. Windows 25H2 (released in September) was released with the patch. Windows 1123h2 and earlier versions remain vulnerable.

Base Score: CVSS 5.5

Vector String CVSS: 3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Crash Reproduction Summary

Executing the PoC as an unprivileged user causes the system to crash immediately. The system enters an unrecoverable state, at which point KeBugCheckEx is invoked. The behavior originates from an internal routine that checks specific flags within an I/O request structure. In the tested scenario, the relevant flags are disabled, which results in incorrect flow handling and ultimately triggers the BSoD.
 
Here is the KeBugCheckEx function as described by Microsoft:

When the POC is executed, the nt!KeBugCheckEx function is called and the system enters an unrecoverable state.

It comes from CLFS!CClfsRequest::ReadLogPagingIo when it tests the value of flags in IRPstructure.

The tested value of flags= 0x42 had not been documented by Microsoft.

But, I hypothesized that the following reversed values could be the right ones:

Before moving on, let’s look at the meaning of IRP_PAGING_IO.

IRP Flag Behavior

The IRP_PAGING_IO flag (value 0x02) indicates that the I/O request relates to memory paging, such as operations involving the paging file or memory‑mapped files. The IRP_INPUT_OPERATION flag indicates that the I/O operation involves input data transfer.
 

What is IRP_INPUT_OPERATION?

IRP_INPUT_OPERATION is a flag bit in the I/O Request Packet (IRP) structure used in Windows kernel drivers. It indicates that the I/O operation involves input data transfer (e.g., reading from a device or file).

For correct function behavior, one of these flags should be enabled. In the PoC scenario, both were disabled, which resulted in the incorrect handling path that triggered the BSoD.

PoC Overview (Sanitized)

The PoC is conceptually simple; it contains only two API calls and does not require manipulation of crafted files. Using ReadFile call with the handle returned by CreateLogFile call causes unexpected behavior, as the combination is not typically used in this context. The system does not handle this call sequence correctly, and a BSoD occurs.

This call to ReadFile is not expected and not managed correctly. Consequently, the BSoD is immediately produced.

References

Previous CLFS vulnerabilities that I researched:

Common Log File System (CLFS) file format BLF information can be obtained from these links:

contacts:

Ricardo.narvaja@fortra.com 
@ricnar456

Comments are closed.