CVE-2025-54110-Kernel-EoP-PoC

PoC implementation for CVE-2025-54110 a Kernel-Level Integer Overflow Vulnerability in the Windows NtQueryDirectoryObject system call.

CVE-2025-54110 - Windows Kernel Integer Overflow Analysis

CVE: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-54110

This repository contains a Crash-Only PoC for CVE-2025-54110 Kernel EoP Vulnerability, developed solely for security research, reverse engineering and exploit development research. This code is intended to demonstrate vulnerability research techniques including:

• Binary diffing with Ghidra Version Tracking
• Windows Patch Tuesday analysis
• Kernel vulnerability research methodologies
• Structured Exception Handling (SEH) behavior analysis

This PoC does NOT achieve privilege escalation or reliable BSOD. It is designed to safely trigger access violations that are caught by Windows kernel protections.

---

Overview

CVE-2025-54110: Windows Kernel EoP Vulnerability

Publication Date: September 2025 (Windows Tuesday Security Patch)

Property	Value
CWE	CWE-190: Integer Overflow or Wraparound
CVSS 3.1 Score	8.8 (High) / 7.7 (Temporal)
Vector String	CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C
Attack Vector	Local
Attack Complexity	Low
Privileges Required	Low
User Interaction	None
Scope	Changed
Confidentiality	High
Integrity	High
Availability	High
Exploit Maturity	Unproven

Executive Summary

An integer overflow vulnerability in the Windows Kernel allows an authenticated attacker to potentially elevate privileges locally. According to Microsoft's advisory:

"An attacker could exploit this vulnerability by sending specially crafted input from a sandboxed user-mode process to trigger an integer overflow, resulting in a buffer overflow in the kernel and enabling privilege escalation or sandbox escape."

Potential Impact

• SYSTEM privileges could be gained by a successful attacker
• Sandbox escape from user-mode restricted processes
• Kernel memory corruption leading to code execution

Exploitability Assessment

• Publicly Disclosed: No
• Exploited in the Wild: No
• Microsoft Assessment: Exploitation More Likely

---

Research Methodology

1. Patch Analysis Workflow

Windows Update Files from Aug 2025 & Sep 2025 (KB.msu)
    ↓
Extract CAB Files
    ↓
Calculate SHA-256 Hashes (August vs September)
    ↓
Identify Changed Files
    ↓
Ghidra Version Tracking Analysis
    ↓
Setting Symbol Servers to Clarify Function Names
    ↓
Function-Level Diff Comparison

2. Files Analyzed

Initial analysis focused on two primary kernel components:

win32k.sys (-)

• Result: No significant changes detected
• Score Range: 0.97-1.0 (high similarity)
• Conclusion: Not the vulnerable component for CVE-2025-54110

ntoskrnl.exe (+)

• Result: Multiple functions with significant changes
• Score Range: Functions with scores ≤0.951
• Length Differences: Source vs Destination byte length variations detected
• Total Items Exported: 2,036 functions for analysis

3. Ghidra Version Tracking Results

Sample of identified changes in ntoskrnl.exe:

Score	Confidence	Source Length	Dest Length	Source Function	Dest Function
0.951	2.618	1023	365	FUN_1403146d0	FUN_1403a4ea0
0.950	2.285	113	203	FUN_140680810	FUN_1406d952c
0.950	3.137	782	1050	FUN_14032106c	FUN_140303a38
0.951	2.675	141	171	FUN_140407bd0	FUN_140a172a0
0.951	2.660	346	150	FUN_140610e60	FUN_1406115d4

---

PoC Statement

Technical Approach

The PoC (precise_overflow_bsod.c) attempts to trigger the integer overflow vulnerability through:

1. Precise Threshold Calculation: 0xfffffdbc (derived from base=0x20, name=0x200)
2. NtQueryDirectoryObject API: Target function for triggering overflow
3. Multi-phase Attack Strategy:
   • Phase 1: Precision integer overflow attempts
   • Phase 2: Kernel memory targeting
   • Phase 3: Multi-threaded exploitation

Code Structure

// Key threshold values calculated for overflow
ULONG precise_thresholds[] = {
    0xfffffdbc,  // Precise threshold - base=0x20, name=0x200
    0xfffffdbb,  // Threshold - 1
    0xfffffdbd,  // Threshold + 1
    0xfffffdba,  // Threshold - 2  
    0xfffffdbe,  // Threshold + 2
};

// Buffer configurations to test edge cases
PVOID buffer_types[] = {
    VirtualAlloc(NULL, 0x1000, MEM_COMMIT, PAGE_READWRITE),  // Normal buffer
    VirtualAlloc(NULL, 0x10, MEM_COMMIT, PAGE_READWRITE),    // Small buffer
    NULL,                                                    // NULL pointer
    (PVOID)0x4141414141414141,                              // Invalid pointer
    (PVOID)0x0000000000000000,                              // Zero address
};

Exploitation Vectors Tested

NtQueryDirectoryObject() Parameters:
├── DirectoryHandle: \BaseNamedObjects, \KernelObjects, etc.
├── Buffer: Various pointer configurations
├── BufferLength: Calculated overflow thresholds (0xfffffdbc variants)
├── ReturnSingleEntry: TRUE/FALSE variations
├── RestartScan: TRUE/FALSE variations
└── Context: Controlled iteration state

---

Why the PoC Doesn't Crash the System

Actual Results

The PoC consistently returns STATUS_ACCESS_VIOLATION (0xC0000005) without causing a Blue Screen of Death (BSOD). This is by design and demonstrates several critical Windows kernel security mechanisms:

1. Structured Exception Handling (SEH)

User-Mode Input → NtQueryDirectoryObject
                        ↓
                  ProbeForRead/Write
                        ↓
                  __try { ... }
                        ↓
              Access Violation Detected
                        ↓
                  __except { ... }
                        ↓
            Return STATUS_ACCESS_VIOLATION

Why it works:

• Windows kernel syscalls wrap user-mode pointer access in exception handlers
• Invalid memory accesses are caught rather than allowed to propagate
• System returns error code to caller instead of crashing

2. SMAP (Supervisor Mode Access Prevention)

Modern CPU feature that prevents kernel mode (Ring 0) from accessing user-mode (Ring 3) memory without explicit authorization:

Kernel attempts to access user pointer
        ↓
SMAP checks permission (STAC/CLAC instructions)
        ↓
Unauthorized access detected
        ↓
CPU generates #PF (Page Fault)
        ↓
Caught by kernel exception handler

Impact on PoC:

• Even if overflow occurs, direct kernel-to-user memory access is blocked
• Prevents exploitation of pointer dereference vulnerabilities

3. KASLR (Kernel Address Space Layout Randomization)

Boot Time: Kernel Base = Random Address
                ↓
Hardcoded PoC address (0xfffffdbc)
                ↓
        Does NOT match actual kernel structures
                ↓
    Write to non-critical memory OR caught by SEH

Why BSOD doesn't occur:

• PoC uses static addresses/thresholds
• Real kernel structures are at randomized locations
• Writes miss critical targets (e.g., EPROCESS, Pool Headers)

4. Kernel Pool Integrity Checks

Windows 10+ implements enhanced pool corruption detection:

Heap/Pool Allocation
    ↓
Header Contains:
├── Magic Values
├── Size Information
└── Checksums
    ↓
On Free/Access:
    Validate Integrity
    ↓
Corruption Detected?
    ↓
[YES] → Safe Exception → Return Error
[NO]  → Proceed Normally

---

PoC Execution Output Analysis

Expected Output

See the STATUS_ACCESS_VIOLATION (0xC0000005), then its ok.