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.

The call stack is:

1: kd> k
# Child-SP          RetAddr               Call Site
00 fffff88d`239a0e98 fffff803`74d66612     nt!DbgBreakPointWithStatus
01 fffff88d`239a0ea0 fffff803`74d65cd3     nt!KiBugCheckDebugBreak+0x12
02 fffff88d`239a0f00 fffff803`74c14ad7     nt!KeBugCheck2+0xba3
03 fffff88d`239a1670 fffff803`796d90cf     nt!KeBugCheckEx+0x107
04 fffff88d`239a16b0 fffff803`796c82e8     CLFS!CClfsRequest::ReadLogPagingIo+0xfc2f
05 fffff88d`239a1720 fffff803`796c785e     CLFS!CClfsRequest::Dispatch+0x9c
06 fffff88d`239a1770 fffff803`796c77a7     CLFS!ClfsDispatchIoRequest+0x8e
07 fffff88d`239a17c0 fffff803`74a66f65     CLFS!CClfsDriver::LogIoDispatch+0x27
08 fffff88d`239a17f0 fffff803`74ec433f     nt!IofCallDriver+0x55
09 fffff88d`239a1830 fffff803`74ef3c04     nt!IopSynchronousServiceTail+0x46f
0a fffff88d`239a18e0 fffff803`74ef36fb     nt!IopReadFile+0x4d4
0b fffff88d`239a19e0 fffff803`74c2a005     nt!NtReadFile+0xdb
0c fffff88d`239a1a70 00007ff8`410b04a4     nt!KiSystemServiceCopyEnd+0x25
0d 00000008`7d0ffc28 00007ff8`3e51c308     ntdll!NtReadFile+0x14
0e 00000008`7d0ffc30 00007ff6`b6658e1e    KERNELBASE!ReadFile+0x108
0f 00000008`7d0ffca0 000001cf`4e5abdc0    ConsoleApplication12+0x8e1e

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

In the case of my POC, the value of AL was 0x0 and this directly lead to a call of KeBugCheckEx:

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.