If a driver runs in kernel mode it obviously can manipulate everything (well everything in ring 0), so manipulating the file system or devices is a possibility. Potentially devices can be destroyed, for example by manipulating acpi, stopping the ventilators, ....

However, when the driver runs in user-mode I'm not sure what damage can be done, as I'm not completely aware what capabilities the drivers have.

  • Are the user mode drivers restricted to the device they are inteded for?
  • How do they communicate with the device (obviously DMA or something similar is not possible)?

The main question is: If I have a malicious driver in user mode what can I expect to happen and what won't happen? Everything under the assumption, that the security mechanisms of Windows work as intended.

  • How do you define "damage"? Physical damage? Loss in confidentiality, integrity or availability of your files? Someone mining bitcoin on your machine?
    – user163495
    Commented Aug 9, 2021 at 14:17
  • Drivers in userspace is a design principle of microlithic kernel. It won't be able to compromise the system, the vulnerability will only affect user apps.
    – defalt
    Commented Aug 9, 2021 at 17:31
  • @MechMK1 The most important part is physical damage, but anything else is also of interest.
    – BenjaminH
    Commented Aug 10, 2021 at 6:11

1 Answer 1


User-mode drivers "plug into" a kernel interface for interacting with hardware, so in theory they can do approximately anything that a kernel-mode driver can do, aside from things that the driver framework doesn't support. For example, if the hardware maps its I/O to specific physical memory addresses, the kernel can map those addresses to the user-mode process; true DMA is not available from user-mode, but a user-mode driver can request that the kernel map arbitrary memory ranges into its address space.

User-mode drivers also usually run with very high privileges, including the ability to install kernel-mode drivers if so desired. The point of user-mode drivers is to make them easier to develop and debug, and less likely to trigger a kernel panic if they fail (though note that e.g. two WDDM user-mode video driver crashes in rapid succession will still cause a panic, or would last time I tested extremely beta NVidia drivers). It is not a matter of protecting the machine, either its data or its hardware, from malicious code. Don't load untrustworthy drivers, kernel or otherwise!

Are the user mode drivers restricted to the device they are inteded for?

As far as I know, there's nothing stopping a driver from being loaded for the wrong device in a category, and I'm not sure if it's even limited by category. It's possible from the built-in Device Manager to load entirely the wrong driver for any device (you have to click a lot of buttons that almost nobody has needed in the past decade or two, and you'll get a warning that Windows can't be sure the driver will work, but it won't actually stop you from trying). Given the privileges of user-mode drivers, they could call the same APIs as Device Manager. Alternatively, drivers (at least, in the kernel, and I believe user-mode too) are polled for compatibility with new hardware (this is how plug-and-play works) and a malicious one could just announce itself as working for every device.

With that said, it's worth noting that lots of hardware has its own protections against various failures. Thermal shutoffs, firmware signature checks, bounds-checkers on commands that translate to physical actions or voltage/current levels, and so on all make it much harder to destroy hardware with malicious software than it used to be. That's not to say it's impossible, especially if things like "halfway-flash the firmware and then leave the device in an inoperable state" count (though modern motherboards, at least, often have a backup copy of the old firmware).

  • You certainly used to be able to modify .inf files and get drivers to install and be used for the "wrong" hardware. This was handy to get some USB devices working on earlier versions of windows than thy were built for, by loading the drivers of a predecessor device (I did it with webcams and USB sticks, for example)
    – Chris H
    Commented Aug 10, 2021 at 14:21
  • 1
    @ChrisH yes, that also works. But you can simply force Windows to use an arbitrary INF for arbitrary hardware too, via Device Manager and the "have disk" button when manually picking a driver.
    – CBHacking
    Commented Aug 10, 2021 at 16:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .