lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 4 Aug 2022 16:44:47 -0700 From: Peilin Ye <yepeilin.cs@...il.com> To: Stefano Garzarella <sgarzare@...hat.com> Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Peilin Ye <peilin.ye@...edance.com>, virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH RFC net-next] vsock: Reschedule connect_work for O_NONBLOCK connect() requests Hi Stefano, On Thu, Aug 04, 2022 at 08:59:23AM +0200, Stefano Garzarella wrote: > The last thing I was trying to figure out before sending the patch was > whether to set sock->state = SS_UNCONNECTED in vsock_connect_timeout(). > > I think we should do that, otherwise a subsequent to connect() with > O_NONBLOCK set would keep returning -EALREADY, even though the timeout has > expired. > > What do you think? Thanks for bringing this up, after thinking about sock->state, I have 3 thoughts: 1. I think the root cause of this memleak is, we keep @connect_work pending, even after the 2nd, blocking request times out (or gets interrupted) and sets sock->state back to SS_UNCONNECTED. @connect_work is effectively no-op when sk->sk_state is TCP_CLOS{E,ING} anyway, so why not we just cancel @connect_work when blocking requests time out or get interrupted? Something like: diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index f04abf662ec6..62628af84164 100644 --- a/net/vmw_vsock/af_vsock.c +++ b/net/vmw_vsock/af_vsock.c @@ -1402,6 +1402,9 @@ static int vsock_connect(struct socket *sock, struct sockaddr *addr, lock_sock(sk); if (signal_pending(current)) { + if (cancel_delayed_work(&vsk->connect_work)) + sock_put(sk); + err = sock_intr_errno(timeout); sk->sk_state = sk->sk_state == TCP_ESTABLISHED ? TCP_CLOSING : TCP_CLOSE; sock->state = SS_UNCONNECTED; @@ -1409,6 +1412,9 @@ static int vsock_connect(struct socket *sock, struct sockaddr *addr, vsock_remove_connected(vsk); goto out_wait; } else if (timeout == 0) { + if (cancel_delayed_work(&vsk->connect_work)) + sock_put(sk); + err = -ETIMEDOUT; sk->sk_state = TCP_CLOSE; sock->state = SS_UNCONNECTED; Then no need to worry about rescheduling @connect_work, and the state machine becomes more accurate. What do you think? I will ask syzbot to test this. 2. About your suggestion of setting sock->state = SS_UNCONNECTED in vsock_connect_timeout(), I think it makes sense. Are you going to send a net-next patch for this? 3. After a TCP_SYN_SENT sock receives VIRTIO_VSOCK_OP_RESPONSE in virtio_transport_recv_connecting(), why don't we cancel @connect_work? Am I missing something? Thanks, Peilin Ye
Powered by blists - more mailing lists