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
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Reply via email to