Bug 200131
Summary: | Double-Fetch bug in Linux-4.16.8/drivers/virt/vboxguest/vboxguest_linux.c. | ||
---|---|---|---|
Product: | Drivers | Reporter: | Pengfei Wang (wpengfeinudt) |
Component: | Other | Assignee: | drivers_other |
Status: | NEW --- | ||
Severity: | normal | ||
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | Linux-4.16.8 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | source files and patch |
Created attachment 276675 [details] source files and patch Hello, I found a double-fetch vulnerability in Linux-4.16.8/drivers/virt/vboxguest/vboxguest_linux.c. In function vbg_misc_device_ioctl(), the driver fetches data from the same user address by copy_from_user(), and such data copy occurs twice at line 94 and line 124, respectively. The first fetch copies the message header (stored in hdr), which is used to verify the variables (line 97-102) , such as hdr.version, hdr.size_in, and hdr.size_out. Then, a kernel buffer is allocated based on the size variables (line 117-122) . In the second fetch (line 124), the whole message is copied into the buffer, and the header part is copied again. Since the header part is double-fetched, the critical variables such as hdr.size_in and hdr.size_out are only verified after the first fetch but not after the second fetch. The developer believes the data won’t change, as the annotation in vboxquest_core.c says “hdr->version and hdr->size_in / hdr->size_out minimum size are already checked by vbg_misc_device_ioctl(). ” However, the user data could be tampered between the two fetches by a concurrently running user thread under a race condition, which is a typical double-fetch vulnerability. The kernel buffer is allocated based on the variables from the first fetch, whereas the buffer is used with variables from the second fetch in vbg_core_ioctl() (line 131). We can see from vbg_core_ioctl(), both hdr.size_in, and hdr.size_out are retrieved from the new header and used. A malicious data tamper from the user side can lead to a kernel buffer over-access. I have proposed a patch for this vulnerability, and hope this can be fix as soon as possible, thanks! Pengfei Wang HUNTER Group