In this blog post, we’ll explore one of the classic yet dangerous bugs—null pointer dereference. We’ll break down what it really means, build a custom vulnerable driver, and see firsthand how it can bring down an entire Windows system with a blue screen of death (BSOD).
Introduction
A null pointer dereference happens when a driver tries to access memory through a pointer that hasn’t been properly initialized—usually pointing to address 0x0. In user mode, this might just crash an app, but in kernel mode, it’s a lot more serious. Since the kernel operates with full system privileges with limited error handling, dereferencing a null pointer can trigger a blue screen of death (BSOD) and bring down the entire system. These bugs often slip through when developers assume a pointer is valid without checking, making them both common and dangerous.
Simple NULL Pointer Dereference Vulnerability (Video Buffer Simulation)
We’re looking at a small, simple but deadly custom driver that pretends to be a graphics/video driver. It randomly fails to allocate a “video buffer” and then blindly writes a 0xDEADBEEF magic value, even if the buffer is NULL! We intentionally crash the system (BSOD) for fun, and if you open a debugger, you’ll spot the famous DEADBEEF pattern in memory.
The vulnerability arises because the driver attempts to write 0xDEADBEEF to a video buffer without verifying if the memory allocation succeeded. If the buffer allocation fails and returns NULL, this write will cause a NULL pointer dereference, leading to an instant system crash (BSOD).
Simple BSOD with Null Pointer Dereference in a Custom Driver
In my custom driver, I’ve implemented a vulnerable IOCTL handler that simulates a simple video buffer allocation. One of the vulnerabilities involves a NULL pointer dereference triggered when the allocation randomly fails and the driver blindly writes to the NULL pointer.
This isn’t a full exploitation write-up—just a demonstration of how careless memory handling in drivers can crash the system. We’ll explore advanced exploitation paths in future posts.
The Windows Debugger shows a crash in the DispatchIoctl function of my custom driver, specifically at the instruction mov dword ptr [rdi], 0xDEADBEEF, where RDI is NULL. This confirms a classic NULL pointer dereference, as the kernel attempts to write to address 0x0, causing a SYSTEM_THREAD_EXCEPTION_NOT_HANDLED BSOD. This happens because the video buffer allocation failed and the pointer remained NULL, but the driver blindly wrote to it, leading to the crash.
Null Pointer Dereference in a Custom TCP-like Windows Kernel Driver
This is a null pointer dereference vulnerability embedded in a custom Windows kernel driver that mimics processing of TCP-like network packets. We created our own structure, TCP_HEADER, which includes a field named PayloadPointer—intended to represent a pointer to the packet’s actual data.
The vulnerability arises because the driver assumes that this pointer is always valid, without performing any null or sanity checks. If a malicious user-mode application crafts a TCP_HEADER with PayloadPointer set to NULL and passes it to the driver, the kernel will blindly attempt to access *(NULL).
Simple BSOD with Null Pointer Dereference in a Custom Driver
In my custom driver, I’ve implemented a vulnerable IOCTL handler that simulates TCP packet parsing. One of the vulnerabilities involves a null pointer dereference triggered by sending a TCP-like structure with a PayloadPointer set to NULL. This isn’t a full exploitation write-up, just a demonstration of how a malformed user-supplied packet can crash the kernel. We’ll explore advanced exploitation paths in future posts.
The Windows Debugger shows a crash in the DeviceIoControlHandler function, specifically at the instruction movzx edx, byte ptr [rax], where rax is NULL. This confirms a classic null pointer dereference, as the kernel tries to read from address 0x0, leading to a SYSTEM_THREAD_EXCEPTION_NOT_HANDLED BSOD.
In kernel mode, dereferencing a null pointer doesn’t just crash the app—it crashes the whole system, triggering a blue screen of death (BSOD) with the familiar SYSTEM_THREAD_EXCEPTION_NOT_HANDLED bug check.
Null Pointer Dereference in Custom EDR Driver: File Path Vulnerability
This is a null pointer dereference vulnerability in a custom-built Windows kernel driver that simulates how an EDR (Endpoint Detection and Response) component might scan executable files provided by user-mode. The vulnerability arises when the driver blindly trusts a user-supplied pointer to a file path without checking if it’s valid.
The driver receives a FILE_SCAN_REQUEST structure from user mode. This structure includes a pointer (Filename) and a length (FilenameLength). The idea is to copy the filename string into a local kernel buffer (scanBuffer) so the driver can inspect or scan the file for threats.
This line tries to copy a filename string from a user-supplied structure into a local buffer for scanning or logging. The problem? The driver never checks whether request->Filename is a valid, non-NULL pointer. If user mode sends a NULL here, the driver blindly dereferences 0x0.
Simple BSOD with Null Pointer Dereference in a Custom EDR Driver
I wrote a user-mode tool that prompts for a file path and sends it to the kernel via DeviceIoControl.
If I provide a legit path, the driver attempts to scan the file normally. But if I just hit Enter without typing anything, it sends a NULL pointer.
The CPU raises a page fault, and Windows responds with a BSOD. This is a classic null pointer dereference, often caused by developers assuming the user-supplied pointer is always valid.
In older Windows versions (XP, Vista, 7), null pointer dereference vulnerabilities in kernel drivers could be exploited by mapping the NULL page (0x0) from user mode and placing attacker-controlled data there. If the kernel dereferenced a null pointer, this would lead to arbitrary code execution in ring 0, enabling full system compromise. Starting with Windows 8, Microsoft mitigated this entire class of bugs by blocking NULL page allocation and disabling NTVDM by default. NTVDM (used for running 16-bit apps on x86 systems) previously allowed NULL page mapping, which attackers abused to revive this old technique on Windows 10 x86. Today, these mitigations effectively neutralize most null dereference exploits in modern Windows systems.
Conclusion
In this post, we first explored a simple NULL pointer dereference vulnerability in a video buffer allocation, which could lead to a BSOD. Then, we demonstrated a more complex issue with a TCP-like packet structure, where a NULL PayloadPointer caused a crash, similar to real-world network driver bugs. Additionally, we looked at an EDRScan driver simulating a file path scan, showing how improper validation can lead to vulnerabilities. These issues often arise when drivers fail to handle allocation failures or malformed structures properly. This post serves as a reminder of how critical proper memory handling and structure validation are in preventing common driver vulnerabilities. As we’ve seen, whether it’s in graphics, network drivers, or EDR tools, simple mistakes like NULL pointer dereferences can lead to severe system crashes or security flaws.
