CWE-781 is a driver-level weakness on Windows NT family systems. An IOCTL is defined with the METHOD_NEITHER transfer type, and the code does not validate, or validates incorrectly, the addresses it is handed.
If you write or review kernel drivers in C or C++, this is part of your job. If you only buy software that ships drivers, it is a reason to keep drivers updated.
How it happens
IOCTL stands for I/O control. A user-mode program sends a control code and buffers to a driver. With most transfer methods, the I/O manager checks and copies the buffers for the driver. With METHOD_NEITHER it does not. MITRE states that the IOCTL itself is responsible for validating the supplied addresses.
If the driver trusts the pointers it receives, a caller can pass any address it likes, including kernel memory addresses. The driver then reads or writes at a location chosen by the attacker, running with kernel privilege.
A sketch of the mistake:
case IOCTL_DO_WORK:
// METHOD_NEITHER: pointers come straight from the caller
char *in = irpSp->Parameters.DeviceIoControl.Type3InputBuffer;
char *out = Irp->UserBuffer;
memcpy(out, internalData, len); // no probe, no exception handling
break;
What an attacker gains
The record lists modifying memory, reading memory, executing unauthorized code or commands, and crashes or restarts. In plain terms: arbitrary read and write in kernel space, which usually means full control of the machine.
The MITRE examples show the range. CVE-2006-2373 is a driver for a file-sharing and messaging protocol that allowed arbitrary code execution. CVE-2009-0686 is an anti-virus product whose missing address validation let attackers gain SYSTEM privileges. CVE-2009-0824 is DVD software where the result was a crash.
How to find it
The record lists no detection methods, so use general practice:
- Grep driver sources for METHOD_NEITHER and review every handler that uses it.
- Check that each user pointer is probed for the right access before use and that access sits inside structured exception handling.
- Fuzz the device interface with random control codes and bad pointers on a test machine.
- Inventory third-party drivers on your fleet and track their versions.
How to fix it
- Prefer buffered or direct I/O. Pick METHOD_NEITHER only when you have a measured reason.
- If you must use it, probe and lock user buffers before touching them, and wrap the access so a bad pointer raises an exception you handle.
- Copy input into kernel memory first, then validate the copy. This avoids a caller changing the data after you checked it.
- Validate lengths as well as addresses.
- Limit who can open the device. See CWE-782 on exposed IOCTLs for the access control side.
Quick check
Why does METHOD_NEITHER create risk?
The I/O manager does no validation or copying. The driver gets raw caller pointers and must check them itself.
