similar to: [PATCH] VMCI: Check userland-provided datagram size

From: Jorgen Hansen <jhansen at vmware.com> (this is a resend of this patch. Originally sent last year, but post appears to have been lost) This change fixes two bugs in the VMCI host driver related to mapping the notify boolean from user space into kernel space: - the actual UVA was rounded up to the next page boundary - resulting in memory corruption in the calling process whenever

From: Jorgen Hansen <jhansen at vmware.com> (this is a resend of this patch. Originally sent last year, but post appears to have been lost) This change fixes two bugs in the VMCI host driver related to mapping the notify boolean from user space into kernel space: - the actual UVA was rounded up to the next page boundary - resulting in memory corruption in the calling process whenever

To allow other transports to be loaded with vmci_transport, we register the vmci_transport as G2H or H2G only when a VMCI guest or host is active. To do that, this patch adds a callback registered in the vmci driver that will be called when a new host or guest become active. This callback will register the vmci_transport in the VSOCK core. If the transport is already registered, we ignore the

From: Jorgen Hansen <jhansen at vmware.com> The current maximum size of a queue in a queue pair is 128 MB. If we increase that in the future, the queue pair allocation routines may run into overflow issues. This change adds additional checks to guard against this. Acked-by: Andy King <acking at vmware.com> Reported-by: Dan Carpenter <dan.carpenter at oracle.com> Signed-off-by:

From: Jorgen Hansen <jhansen at vmware.com> The current maximum size of a queue in a queue pair is 128 MB. If we increase that in the future, the queue pair allocation routines may run into overflow issues. This change adds additional checks to guard against this. Acked-by: Andy King <acking at vmware.com> Reported-by: Dan Carpenter <dan.carpenter at oracle.com> Signed-off-by:

> From: Stefano Garzarella [mailto:sgarzare at redhat.com] > Sent: Wednesday, October 23, 2019 11:56 AM > > To allow other transports to be loaded with vmci_transport, > we register the vmci_transport as G2H or H2G only when a VMCI guest > or host is active. > > To do that, this patch adds a callback registered in the vmci driver > that will be called when a new host

> From: Stefano Garzarella [mailto:sgarzare at redhat.com] > Sent: Wednesday, October 23, 2019 11:56 AM > > To allow other transports to be loaded with vmci_transport, > we register the vmci_transport as G2H or H2G only when a VMCI guest > or host is active. > > To do that, this patch adds a callback registered in the vmci driver > that will be called when a new host

> From: Stefano Garzarella [mailto:sgarzare at redhat.com] > Sent: Monday, November 11, 2019 6:31 PM > On Mon, Nov 11, 2019 at 04:27:28PM +0000, Jorgen Hansen wrote: > > > From: Stefano Garzarella [mailto:sgarzare at redhat.com] > > > Sent: Wednesday, October 23, 2019 11:56 AM > > > > > > To allow other transports to be loaded with vmci_transport, >

On Mon, Nov 11, 2019 at 04:27:28PM +0000, Jorgen Hansen wrote: > > From: Stefano Garzarella [mailto:sgarzare at redhat.com] > > Sent: Wednesday, October 23, 2019 11:56 AM > > > > To allow other transports to be loaded with vmci_transport, > > we register the vmci_transport as G2H or H2G only when a VMCI guest > > or host is active. > > > > To do

This change consists of two changes: 1) If vmci_doorbell_create is called when neither guest nor host personality as been initialized, vmci_get_context_id will return VMCI_INVALID_ID. In that case, we should fail the create call. 2) In doorbell destroy, we assume that vmci_guest_code_active() has the same return value on create and destroy. That may not be the case, so we may end

This change consists of two changes: 1) If vmci_doorbell_create is called when neither guest nor host personality as been initialized, vmci_get_context_id will return VMCI_INVALID_ID. In that case, we should fail the create call. 2) In doorbell destroy, we assume that vmci_guest_code_active() has the same return value on create and destroy. That may not be the case, so we may end

On Fri, Sep 21, 2018 at 12:31:05AM -0700, Jorgen Hansen wrote: > When adding a VMCI resource, the check for an existing entry > would ignore that the new entry could be a wildcard. This could > result in multiple resource entries that would match a given > handle. One disastrous outcome of this is that the > refcounting used to ensure that delayed callbacks for VMCI > datagrams

On Fri, Sep 21, 2018 at 12:31:05AM -0700, Jorgen Hansen wrote: > When adding a VMCI resource, the check for an existing entry > would ignore that the new entry could be a wildcard. This could > result in multiple resource entries that would match a given > handle. One disastrous outcome of this is that the > refcounting used to ensure that delayed callbacks for VMCI > datagrams

On 3 Oct 2018, at 00:35, Greg KH <gregkh at linuxfoundation.org<mailto:gregkh at linuxfoundation.org>> wrote: On Fri, Sep 21, 2018 at 12:31:05AM -0700, Jorgen Hansen wrote: When adding a VMCI resource, the check for an existing entry would ignore that the new entry could be a wildcard. This could result in multiple resource entries that would match a given handle. One disastrous

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

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

This change restricts the reading and setting of the head and tail pointers on 32bit X86 to 32bit for both correctness and performance reasons. On uniprocessor X86_32, the atomic64_read may be implemented as a non-locked cmpxchg8b. This may result in updates to the pointers done by the VMCI device being overwritten. On MP systems, there is no such correctness issue, but using 32bit atomics avoids

This change restricts the reading and setting of the head and tail pointers on 32bit X86 to 32bit for both correctness and performance reasons. On uniprocessor X86_32, the atomic64_read may be implemented as a non-locked cmpxchg8b. This may result in updates to the pointers done by the VMCI device being overwritten. On MP systems, there is no such correctness issue, but using 32bit atomics avoids

This patch adds support for virtual IOMMU to the vmci module. We switch to DMA consistent mappings for guest queuepair and doorbell pages that are passed to the device. We still allocate each page individually, since there's no guarantee that we'll get a contiguous block of physical for an entire queuepair (especially since we allow up to 128 MiB!). Also made the split between guest and

* * * This series of VMCI linux upstreaming patches include latest udpate from VMware. -split guest, host and core driver code into different files -use EXPORT_SYMBOLS_GPL -remove vmci_device_get and vmci_device_release APIs -simplify the event deliver mechanism -driver ioctl code cleanup -sparse clean * * * In an effort to improve the out-of-the-box experience with