From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f70.google.com (mail-ot1-f70.google.com [209.85.210.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1DAE6340260 for ; Fri, 24 Apr 2026 05:18:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.70 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777007905; cv=none; b=Ad/D411g9guSmzl70YOQMRIuG9heqpaLNogWKq/r5RhMLRqgK6RISb/NCFzDoHs8RwFpCLVGQhrSypark963jHQX+UrzDRmPoRXUogBgJNTg2OGl5AE53EW4zjlSj5sJsD2o3/yPCXlEzqmlqsu1/i57qqUFdpJUz93GrzMadqI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777007905; c=relaxed/simple; bh=ITsMsicszaIKnHEhfTT7QkQvSfHd15nhsxsY2W1PYyU=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=XF7/uk+xIUBunzK6Zeh1mnOzDzIpB0ijgOx4Q2HUwoMx9yJddp6SpASbm2Sa+O2poQLEgPHMwiF6M/ShY7D5Rf+Lq5M4n6mHRGysOAe9EBfbn2sx0xghY2jrbO6EjlyUEYzQ4y+709WPCC/j0kJsi95aRbhzozYfvc+YQgdgXmI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.210.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com Received: by mail-ot1-f70.google.com with SMTP id 46e09a7af769-7de44ba64e7so2596726a34.1 for ; Thu, 23 Apr 2026 22:18:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777007903; x=1777612703; h=to:from:subject:message-id:in-reply-to:date:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0jObznM+L7zY4bSiBOcW8n4eKbjP4UYnxClaiENd0nA=; b=qii/r+C7tGfKvx24g2YozUXo6c5ky4Pf6GY1ymVnnfoXLrzsRbr2rWxk7sc1KGDIv9 QTXRY4/sLiIOdSazZlQwz8cbEGUEPHkWeHGWqFZ3wXTcuTQdPacHI4e3qEXX9A7vDebJ 1C7B+Q+OrWhzNsKwflLz7wcPSkxWCBXKMSM07W0XSPVaxI9Pu3QbWaYTuIusrMvkMySC ELpQmU4x6nJwKbPvBFZix7sgkudRSJDXxjKl66aPcmzHz5sJD8gB3vouA4kxQ0FNPXFU cEIOhzLY+BfmpUzOuy9JFXYjtyXFtHzcCrGfp4i4/jcZqmuX8tmz88QpCG6v1r8M+g2Q fC+g== X-Gm-Message-State: AOJu0YyUlgf38IEZqa9WVPoBCV77i1r+mVUNZy/3FmYsDePN35xtWJOA ArYgFTyLdlZ4cZagLySqiG9BkTO0nWNoZD9ct3jePSC7pSQMR2FSCfvizFqkBryT0XOWoJxVj4e y9nBZ5299rGGHdgKhQt/HXoNBGodpMftD9aPYdovFgqx9u5XQrSKwBL8og1A= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a05:6820:178d:b0:694:9e11:dd51 with SMTP id 006d021491bc7-6949e11dfcbmr7278882eaf.24.1777007902733; Thu, 23 Apr 2026 22:18:22 -0700 (PDT) Date: Thu, 23 Apr 2026 22:18:22 -0700 In-Reply-To: <69eacf39.a00a0220.17a17.004d.GAE@google.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <69eafd1e.a00a0220.9259.0032.GAE@google.com> Subject: Forwarded: [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen() From: syzbot To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" For archival purposes, forwarding an incoming command email to linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com. *** Subject: [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen() Author: kartikey406@gmail.com #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master Two bugs exist in virtio_transport_recv_listen(): 1. On the transport assignment error path, sk_acceptq_added() is called but sk_acceptq_removed() is never called when vsock_assign_transport() fails or assigns a different transport than expected. This causes the parent listener's accept backlog counter to be permanently inflated, eventually causing sk_acceptq_is_full() to reject legitimate incoming connections. 2. There is a race between __vsock_release() and vsock_enqueue_accept(). __vsock_release() sets sk->sk_shutdown to SHUTDOWN_MASK and flushes the accept queue under the parent socket lock. However, virtio_transport_recv_listen() checks sk_shutdown and subsequently calls vsock_enqueue_accept() without holding the parent socket lock. This means a child socket can be enqueued after __vsock_release() has already flushed the queue, causing the child socket and its associated resources (struct sock, LSM blob, virtio transport data) to leak permanently. The existing comment in the code hints at this race but the fix was never implemented. Fix both issues: add sk_acceptq_removed() on the transport error path, and re-check sk->sk_shutdown under the parent socket lock before calling vsock_enqueue_accept() to close the race window. The child socket lock is released before acquiring the parent socket lock to maintain correct lock ordering (parent before child). Reported-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678 Signed-off-by: Deepanshu Kartikey --- net/vmw_vsock/virtio_transport_common.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c index 416d533f493d..fad5fa4a4296 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -1578,6 +1578,7 @@ virtio_transport_recv_listen(struct sock *sk, struct sk_buff *skb, */ if (ret || vchild->transport != &t->transport) { release_sock(child); + sk_acceptq_removed(sk); virtio_transport_reset_no_sock(t, skb, sock_net(sk)); sock_put(child); return ret; @@ -1588,11 +1589,19 @@ virtio_transport_recv_listen(struct sock *sk, struct sk_buff *skb, child->sk_write_space(child); vsock_insert_connected(vchild); + release_sock(child); + lock_sock(sk); + if (sk->sk_shutdown == SHUTDOWN_MASK) { + release_sock(sk); + sk_acceptq_removed(sk); + virtio_transport_reset_no_sock(t, skb, sock_net(sk)); + sock_put(child); + return -ESHUTDOWN; + } vsock_enqueue_accept(sk, child); + release_sock(sk); virtio_transport_send_response(vchild, skb); - release_sock(child); - sk->sk_data_ready(sk); return 0; } -- 2.43.0