Since this driver is so small, it's also extremely easy to tell what it does. After taking a look, I would never let this product run on my machine.
The driver first registers itself using a pseudo-randomly generated name. That's kind of suspicious. It also doesn't specify any security, so any user at any privilege level can attempt to open and control the device. That's bad.
It sets up custom handlers for opening the device object, closing the device object, and performing ioctls on the device object. This is pretty normal, although a driver that didn't set up basic security when creating its device should perform security checks when opening the device. This driver does not.
The ioctl handler is where everything "interesting" happens. It checks for control codes 0xAA012044 and 0xAA013044, does some buffer size checks, disables supervisor-mode execution protection and then runs the arbitrary code passed in through the ioctl buffer with kernel permissions.
In short, this driver creates a back door which can allow a non-privileged user to run code with permissions of the kernel.
edit: correction to what the driver does with cr4, thanks /u/Mona3000. SMEP is a security feature designed to prevent kernel mode code from ever running user mode code. The driver restores the original value of the bit after running the user code, but that doesn't really improve the situation.
