Hello,
Our UC-KLEE tool discovered a memcpy() read overrun bug in dg_dispatch_as_host() (drivers/misc/vmw_vmci/vmci_datagram.c). This bug may allow a malicious user to leak private kernel heap data across the VMware VMCI interface (in a nearly identical fashion to the OpenSSL Heartbleed vulnerability from 2014), but the impact is probably minimal since this interface is only used for local communication.
The bug occurs for the IOCTL_VMCI_DATAGRAM_SEND ioctl, and our tool reports the following partial backtrace:
#0 memcpy ()
#1 dg_dispatch_as_host () at drivers/misc/vmw_vmci/vmci_datagram.c:245
#2 vmci_datagram_dispatch () at drivers/misc/vmw_vmci/vmci_datagram.c:347
#3 vmci_host_do_send_datagram () at drivers/misc/vmw_vmci/vmci_host.c:404
Here’s the relevant code snippet from dg_dispatch_as_host():
171: dg_size = VMCI_DG_SIZE(dg);
...
235: dg_info = kmalloc(sizeof(*dg_info) +
236: (size_t) dg->payload_size, GFP_ATOMIC);
237: if (!dg_info) {
238: atomic_dec(&delayed_dg_host_queue_size);
239: vmci_resource_put(resource);
240: return VMCI_ERROR_NO_MEM;
241: }
...
245: memcpy(&dg_info->msg, dg, dg_size);
The memcpy() at line 245 copies ‘dg_size’ bytes from the ‘dg’ buffer, which is user-supplied input retrieved via copy_from_user() at drivers/misc/vmw_vmci/vmci_host.c:390. The ‘dg_size’ variable is itself derived from the user-supplied value 'dg->payload_size.'
The only attempt to sanitize ‘dg->payload_size' is in vmci_datagram_dispatch():
331: if (VMCI_DG_SIZE(dg) > VMCI_MAX_DG_SIZE) {
332: pr_devel("Payload (size=%llu bytes) too big to send\n",
333: (unsigned long long)dg->payload_size);
334: return VMCI_ERROR_INVALID_ARGS;
335: }
This provides an upper bound of 69,632 bytes, but it doesn’t relate the payload size to the actual size of the user-supplied datagram. I think there should be a comparison with 'send_info.len’ in vmci_host_do_send_datagram().
Please let me know if you have any questions or need more details.
Thanks,
-David
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
