linux-stable.git/net/vmw_vsock, branch linux-3.16.y

vsock: cope with memory allocation failure at socket creation time

2019-05-02T20:41:50+00:00

commit 225d9464268599a5b4d094d02ec17808e44c7553 upstream.

In the unlikely event that the kmalloc call in vmci_transport_socket_init()
fails, we end-up calling vmci_transport_destruct() with a NULL vmci_trans()
and oopsing.

This change addresses the above explicitly checking for zero vmci_trans()
at destruction time.

Reported-by: Xiumei Mu 
Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Signed-off-by: Paolo Abeni 
Reviewed-by: Stefano Garzarella 
Reviewed-by: Jorgen Hansen 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

VSOCK: Send reset control packet when socket is partially bound

2019-02-11T17:54:27+00:00

commit a915b982d8f5e4295f64b8dd37ce753874867e88 upstream.

If a server side socket is bound to an address, but not in the listening
state yet, incoming connection requests should receive a reset control
packet in response. However, the function used to send the reset
silently drops the reset packet if the sending socket isn't bound
to a remote address (as is the case for a bound socket not yet in
the listening state). This change fixes this by using the src
of the incoming packet as destination for the reset packet in
this case.

Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Reviewed-by: Adit Ranadive 
Reviewed-by: Vishnu Dasa 
Signed-off-by: Jorgen Hansen 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

vsock: split dwork to avoid reinitializations

2018-11-20T18:05:54+00:00

commit 455f05ecd2b219e9a216050796d30c830d9bc393 upstream.

syzbot reported that we reinitialize an active delayed
work in vsock_stream_connect():

	ODEBUG: init active (active state 0) object type: timer_list hint:
	delayed_work_timer_fn+0x0/0x90 kernel/workqueue.c:1414
	WARNING: CPU: 1 PID: 11518 at lib/debugobjects.c:329
	debug_print_object+0x16a/0x210 lib/debugobjects.c:326

The pattern is apparently wrong, we should only initialize
the dealyed work once and could repeatly schedule it. So we
have to move out the initializations to allocation side.
And to avoid confusion, we can split the shared dwork
into two, instead of re-using the same one.

Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Reported-by: 
Cc: Andy king 
Cc: Stefan Hajnoczi 
Cc: Jorgen Hansen 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

VSOCK: Detach QP check should filter out non matching QPs.

2017-11-26T13:50:40+00:00

commit 8ab18d71de8b07d2c4d6f984b718418c09ea45c5 upstream.

The check in vmci_transport_peer_detach_cb should only allow a
detach when the qp handle of the transport matches the one in
the detach message.

Testing: Before this change, a detach from a peer on a different
socket would cause an active stream socket to register a detach.

Reviewed-by: George Zhang 
Signed-off-by: Jorgen Hansen 
Signed-off-by: David S. Miller 
Signed-off-by: Michal Hocko 
Signed-off-by: Ben Hutchings

VSOCK: Fix lockdep issue.

2017-11-26T13:50:40+00:00

commit 8566b86ab9f0f45bc6f7dd422b21de9d0cf5415a upstream.

The recent fix for the vsock sock_put issue used the wrong
initializer for the transport spin_lock causing an issue when
running with lockdep checking.

Testing: Verified fix on kernel with lockdep enabled.

Reviewed-by: Thomas Hellstrom 
Signed-off-by: Jorgen Hansen 
Signed-off-by: David S. Miller 
Signed-off-by: Michal Hocko 
Signed-off-by: Ben Hutchings

VSOCK: sock_put wasn't safe to call in interrupt context

2017-11-26T13:50:40+00:00

commit 4ef7ea9195ea73262cd9730fb54e1eb726da157b upstream.

In the vsock vmci_transport driver, sock_put wasn't safe to call
in interrupt context, since that may call the vsock destructor
which in turn calls several functions that should only be called
from process context. This change defers the callling of these
functions  to a worker thread. All these functions were
deallocation of resources related to the transport itself.

Furthermore, an unused callback was removed to simplify the
cleanup.

Multiple customers have been hitting this issue when using
VMware tools on vSphere 2015.

Also added a version to the vmci transport module (starting from
1.0.2.0-k since up until now it appears that this module was
sharing version with vsock that is currently at 1.0.1.0-k).

Reviewed-by: Aditya Asarwade 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Jorgen Hansen 
Signed-off-by: David S. Miller 
Signed-off-by: Michal Hocko 
Signed-off-by: Ben Hutchings

VSOCK: do not disconnect socket when peer has shutdown SEND only

2017-03-16T02:27:16+00:00

[ Upstream commit dedc58e067d8c379a15a8a183c5db318201295bb ]

The peer may be expecting a reply having sent a request and then done a
shutdown(SHUT_WR), so tearing down the whole socket at this point seems
wrong and breaks for me with a client which does a SHUT_WR.

Looking at other socket family's stream_recvmsg callbacks doing a shutdown
here does not seem to be the norm and removing it does not seem to have
had any adverse effects that I can see.

I'm using Stefan's RFC virtio transport patches, I'm unsure of the impact
on the vmci transport.

Signed-off-by: Ian Campbell 
Cc: "David S. Miller" 
Cc: Stefan Hajnoczi 
Cc: Claudio Imbrenda 
Cc: Andy King 
Cc: Dmitry Torokhov 
Cc: Jorgen Hansen 
Cc: Adit Ranadive 
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

vsock: Make transport the proto owner

2014-05-05T17:13:50+00:00

Right now the core vsock module is the owner of the proto family. This
means there's nothing preventing the transport module from unloading if
there are open sockets, which results in a panic. Fix that by allowing
the transport to be the owner, which will refcount it properly.

Includes version bump to 1.0.1.0-k

Passes checkpatch this time, I swear...

Acked-by: Dmitry Torokhov 
Signed-off-by: Andy King 
Signed-off-by: David S. Miller

net: Fix use after free by removing length arg from sk_data_ready callbacks.

2014-04-11T20:15:36+00:00

Several spots in the kernel perform a sequence like:

	skb_queue_tail(&sk->s_receive_queue, skb);
	sk->sk_data_ready(sk, skb->len);

But at the moment we place the SKB onto the socket receive queue it
can be consumed and freed up.  So this skb->len access is potentially
to freed up memory.

Furthermore, the skb->len can be modified by the consumer so it is
possible that the value isn't accurate.

And finally, no actual implementation of this callback actually uses
the length argument.  And since nobody actually cared about it's
value, lots of call sites pass arbitrary values in such as '0' and
even '1'.

So just remove the length argument from the callback, that way there
is no confusion whatsoever and all of these use-after-free cases get
fixed as a side effect.

Based upon a patch by Eric Dumazet and his suggestion to audit this
issue tree-wide.

Signed-off-by: David S. Miller

net: add build-time checks for msg->msg_name size

2014-01-19T07:04:16+00:00

This is a follow-up patch to f3d3342602f8bc ("net: rework recvmsg
handler msg_name and msg_namelen logic").

DECLARE_SOCKADDR validates that the structure we use for writing the
name information to is not larger than the buffer which is reserved
for msg->msg_name (which is 128 bytes). Also use DECLARE_SOCKADDR
consistently in sendmsg code paths.

Signed-off-by: Steffen Hurrle 
Suggested-by: Hannes Frederic Sowa 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller