What does a kernel-mode code review cover?

Our reviews examine security vulnerabilities (privilege escalation, improper user-mode input validation), IRQL correctness, memory management (leaks, pool corruption, use-after-free), race conditions and locking discipline, IRP handling correctness, and adherence to Windows Driver Kit best practices. We also look at driver signing, PatchGuard compatibility, and compatibility with Driver Verifier.

How is the code review delivered?

You receive a written report documenting each finding with its location in the source code, an explanation of the issue, its severity, and a prioritized recommendation for fixing it. Critical findings that could cause crashes or security vulnerabilities are highlighted separately so your team knows exactly where to focus first.

Can you review drivers written by another team?

Yes, reviewing drivers written by others — including third-party or offshore teams — is one of the most common scenarios for our code review service. We have no context about design decisions that might bias the review, which is often an advantage.

Windows Driver Code Review Services

Code Reviews & Maintenance

Extra eyes save time.

Driver code review is categorically different from application code review because the failure modes are different. In application code, a bug in memory management produces a process crash or a leak that degrades performance over time — serious, but contained. In kernel-mode driver code, the same class of bug can corrupt memory used by the entire operating system, trigger a Blue Screen of Death on customer machines, expose a privilege escalation vulnerability exploitable by local attackers, or cause a submission failure during WHQL certification. A reviewer who understands kernel memory management, IRQL rules, IRP completion semantics, and the Windows security model will find a different — and more important — set of issues than a competent application engineer applying general code review heuristics.

Do you have to maintain or enhance legacy code that no one knows or wants to touch? We have spent years reading through machine code and figuring out how things work without access to source code. Just imagine what we can do when the source code is in front of us! Going over legacy code to document or leverage existing intellectual property might not be what your team fancies, but we do this for a living and are very comfortable delving into the unknown. When we are done, you'll receive a clear set of actionable recommendations for improving the security, reliability and performance of the existing code.

A kernel-mode code review from Joya Systems covers the areas that matter most in system-level software: security vulnerabilities such as privilege escalation paths and improper input validation from user-mode callers; performance bottlenecks from excessive lock contention or misuse of non-paged pool; IRQL violations where code executes at the wrong interrupt level; memory leaks in kernel allocations; and race conditions in multi-processor scenarios that may only surface under load or on specific hardware configurations. We also check adherence to kernel-mode best practices around object reference counting, IRP handling, and driver unload paths.

At the conclusion of the engagement you receive a written report that documents every finding, categorized by severity and accompanied by a concrete, prioritized list of recommendations. Critical issues, those likely to cause crashes, data corruption, or exploitable vulnerabilities, are flagged clearly so your team can address them first. The report is written to be actionable by your own engineers, so you are not dependent on us to implement the fixes, though we are happy to do so if preferred.

Contact us to get started or to discuss the scope of what you need reviewed. Code review is also a natural complement to our Windows driver development, security and malware analysis, and technical due diligence services.

What We Review

A Joya Systems driver code review examines the following categories of issue, each specific to kernel-mode development and unlikely to be caught by generic static analysis tools or general-purpose code reviewers:

Memory management. Pool allocation and deallocation patterns, including use-after-free, double-free, allocation size mismatches, and failure to handle allocation failure at IRQL above PASSIVE_LEVEL.
Locking and synchronization. Deadlock-prone lock acquisition sequences, IRQL violations such as holding a spinlock while calling a function that may sleep, and races between DPC routines, completion callbacks, and driver dispatch functions.
IRP handling. Correct completion of all IRP paths including error paths, proper use of IoCompleteRequest, pending IRP and cancellation handling, and avoiding IRP reuse bugs.
Security boundaries. Validation of all user-mode inputs through IOCTL interfaces, correct use of ProbeForRead and ProbeForWrite, and protection against integer overflow in size calculations that could be exploited for privilege escalation.
Driver lifecycle. Correct object reference counting, safe driver unload implementation, and correct handling of surprise removal and Plug and Play events.

When to Commission a Code Review

The four most productive times to have driver code reviewed are: before shipping a new driver to customers, so that defects are found before they reach the field; before submitting for WHQL certification, so that avoidable failures do not extend the certification timeline; after acquiring a driver codebase — through acquisition, outsourced development, or technology licensing — to establish an independent baseline of quality before accepting delivery; and after a security incident, to determine whether the driver involved contains additional vulnerabilities beyond the one that was exploited. Code review pairs naturally with our technical due diligence service for acquisition scenarios and with our security consulting for post-incident work. If the driver is only available as a compiled binary without source, our reverse engineering capability extends the same assessment to compiled code.

Frequently Asked Questions

Q: What does a kernel-mode code review cover?: Our reviews examine security vulnerabilities (privilege escalation, improper user-mode input validation), IRQL correctness, memory management (leaks, pool corruption, use-after-free), race conditions and locking discipline, IRP handling correctness, and adherence to Windows Driver Kit best practices. We also look at driver signing, PatchGuard compatibility, and compatibility with Driver Verifier.
Q: How is your code review delivered?: You receive a written report documenting each finding with its location in the source code, an explanation of the issue, its severity, and a prioritized recommendation for fixing it. Critical findings that could cause crashes or security vulnerabilities are highlighted separately so your team knows exactly where to focus first.
Q: Can you review drivers written by another team?: Yes, reviewing drivers that were written by others — including third-party or offshore teams — is one of the most common scenarios for our code review service. We have no context about design decisions that might bias the review, which is often an advantage. Get in touch to send us the code and we will provide an estimate of the effort involved.

Our Services

What our customers say about us?
Read our customer testimonials to find out why our clients keep returning for their projects.
View Testimonials