Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1091

This bug report describes two separate issues that, when combined,
allow any user on a Linux host system on which VirtualBox is installed
to gain code execution in the kernel. Since I'm not sure which one of
these issues crosses something you consider to be a privilege boundary,
I'm reporting them together.

To reproduce, download the attached file
virtualbox-host-r3-to-host-r0-crasher.tar, ensure that at least one VM
is running, then:

/tmp$ tar xf virtualbox-host-r3-to-host-r0-crasher.tar
/tmp$ cd virtualbox-host-r3-to-host-r0-crasher/
/tmp/virtualbox-host-r3-to-host-r0-crasher$ ./attack.sh
./attack.sh: line 7: 82634 Killed                  QT_QPA_PLATFORM_PLUGIN_PATH=fake_qt_platform_plugins /usr/lib/virtualbox/VirtualBox --startvm
/tmp/virtualbox-host-r3-to-host-r0-crasher$ dmesg
[...]
[279468.028025] BUG: unable to handle kernel paging request at 0000000013370028
[...]


The first step of the attack is to get access to the device
/dev/vboxdrv, which can normally only be opened by root:

~$ ls -l /dev/vboxdrv
crw------- 1 root root 10, 54 Jan 17 16:23 /dev/vboxdrv

In order to be able to open this device, the main VirtualBox binary is
setuid root:

$ ls -l /usr/lib/virtualbox/VirtualBox
-r-s--x--x 1 root root 35240 Jan 16 19:55 /usr/lib/virtualbox/VirtualBox

VirtualBox uses its root privileges to open /dev/vboxdrv, then quickly
drops its privileges. However, it retains the open file descriptor to
/dev/vboxdrv. Therefore, an attacker can gain access to the device
/dev/vboxdrv by injecting code into a VirtualBox userspace process.

After dropping privileges, VirtualBox loads various libraries,
including QT, that are not designed to run in a setuid context.
See https://doc.qt.io/qt-5/qcoreapplication.html#setSetuidAllowed :
"Qt is not an appropriate solution for setuid programs due to its
large attack surface." Using the environment variable
QT_QPA_PLATFORM_PLUGIN_PATH, an attacker can let QT load a library
from an arbitrary directory.


The second step is to use the device /dev/vboxdrv to corrupt the
kernel. The SUP_IOCTL_CALL_VMMR0 ioctl takes a pointer to a structure
in ring 0 as an argument (pVMR0) and ends up calling the function
VMMR0EntryEx(). With the attached PoC, this function crashes when
attempting to read pVM->pVMR0. However, an attacker who supplies a
pointer to attacker-controlled kernel memory could reach any point in
the function. For some operations, e.g.
VMMR0_DO_VMMR0_INIT, the attacker-controlled pointer pVM is then used
in vmmR0CallRing3SetJmpEx() to save and restore various kernel
registers, including RSP. By supplying a pointer to which the attacker
can concurrently write data, an attacker can therefore control the
kernel stack and thereby perform arbitrary operations in the kernel.
(As far as I can tell, a comment in VMMR0EntryEx points out this
issue: "/** @todo validate this EMT claim... GVM knows. */")


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/41905.zip