Published:2024/04/23  Last Updated:2024/04/24

Multiple third-party kernel drivers for Windows vulnerable to improper access control on IOCTL


Multiple third-party kernel drivers for Windows are reported vulnerable to improper access control on IOCTL.

Products Affected

  • Third-party kernel drivers for Windows implementing IOCTL interface
Carbon Black researcher reported that multiple WDF (Windows Driver Framework) and WDM (Windows Driver Model) kernel drivers are affected.


On Microsoft Windows, a kernel driver can provide IOCTL interface through which a user application can communicate directly with.
Since a kernel driver can access all the resources of the system, it is important to implement restrictions such that only the administrative user(s) can operate the driver and that the accessible resources through the operation are only within a certain range.

When a kernel driver is not configured with proper access permissions, and/or does not validate properly input data sent from user processes, it may be operated by an unexpected user or may behave in an unexpected manner.


The impact varies depending on the functionality provided by the affected kernel driver. The firmware may be deleted, may be modified, or an attacker may escalate the privilege.

Also, BYOVD (Bring Your Own Vulnerable Driver) attack may be mounted; an attacker with some administrative privilege load a vulnerable driver and send a crafted IOCTL request. It may result in disabling security mechanisms used by some EDR (Endpoint Detection and Response) products, executing a denial of service (DoS) attack at firmware level, or installing a rootkit (bootkit).


Countermeasures on vendor side
Kernel driver developers should follow Driver Security Guidance provided by Microsoft.
The following topics are picked up from the guidance.

Restrict access to device objects to administrative users only
A user process needs to get a handle to a device object generated by a kernel driver to send IOCTL requests.
Therefore, privilege escalation attack can be prevented by restricting access to the device object to administrative users only.
The restriction can be implemented by specifying Security entry of INF AddReg directive in the relevant INF file, or calling APIs such as WdmlibIoCreateDeviceSecure or WdfControlDeviceInitAllocate etc. in the driver's source code.

Limit the range of input values
The access restriction explained above prevents the privilege escalation. But, there are cases that non administrative users' access must be allowed. Also, the access restriction can not prevent BYOVD attack when an administrative user attacks the system.
More general solution is to limit the range of input values from the IOCTL requests. For example, when processing an IOCTL request to communicate with a hardware port, the arguments such as the port number and data values should be checked if they are within the expected ranges. Memory-mapped I/O is the same, values received from the request should be checked, a specified memory address, an address range, register indexes and data specified by MSR (Model-Specific Register) / CR (Control Register) and so on.
As an example, Sangoma Technologies took this approach to fix cg6kwin2k.sys. Before executing I/O with a specified physical memory address, the fixed code checks whether the specified address area is inside the range used by the PCIe adaptor of Sangoma Technologies. If invalid, the I/O request is denied.

Fixed code doing input validation in cg6kwin2k.sys
Fixed code of memory-mapped I/O in cg6kwin2k.sys by Sangoma Technologies

Countermeasures on user side
Keep up-to-date with your drivers
Check the information provided by the developers and keep up-to-date with the drivers in your system. Vendors may provide the update information through their websites, or sometimes provide directly to subscribers only. Confirm how your vendors provide the information.

Keep up-to-date with your operating system
Microsoft releases the vulnerable driver blocklist. Windows 11 2022 Update and later versions block these kernel drivers by default. Vulnerable drivers discovered by Carbon Black seem to be added to this list around January 2024, but Carbon Black observes that the latest version of Windows 11 23H2 (OS build 22631.3447) as of 2024/4/22 does not block these kernel drivers.

Use 3rd-party vulnerable driver lists
Microsoft vulnerable driver blocklist is updated once or twice a year. The latest vulnerable kernel drivers may not be listed.
3rd party lists, such as LOLDrivers, may be a choice to rapidly obtain the latest information on vulnerable kernel drivers.

Vendor Status


  1. Carbon Black
    Hunting Vulnerable Kernel Drivers
  2. Japan Vulnerability Notes JVNVU#93886750
    Phoenix Technologies Windows kernel driver vulnerable to insufficient access control on its IOCTL
  3. Japan Vulnerability Notes JVNVU#97149791
    Advanced Micro Devices Windows kernel drivers vulnerable to insufficient access control on its IOCTL
  4. Japan Vulnerability Notes JVNVU#90671953
    Sangoma Technologies CG/MG family driver cg6kwin2k.sys vulnerable to insufficient access control on its IOCTL

JPCERT/CC Addendum

Vulnerability Analysis by JPCERT/CC


This document is written by Takahiro Haruyama of Broadcom and JPCERT/CC.

Other Information

JPCERT Reports
CERT Advisory
CPNI Advisory
JVN iPedia

Update History

Fixed typo under the [Description] section