* [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen
@ 2026-06-05 19:19 Divya Mankani
2026-06-06 7:19 ` kernel test robot
2026-06-06 14:24 ` [syzbot ci] " syzbot ci
0 siblings, 2 replies; 3+ messages in thread
From: Divya Mankani @ 2026-06-05 19:19 UTC (permalink / raw)
To: kuba, pabeni
Cc: horms, virtualization, kvm, netdev, linux-kernel,
syzbot+1b2c9c4a0f8708082678, Divya Mankani
Syzbot reported a memory leak inside virtio_transport_recv_listen
caused by a race condition when the parent listener socket shuts down
while an incoming packet is being enqueued.
Fix this by locking the parent socket and verifying its shutdown
state under the lock before executing vsock_enqueue_accept().
Fixes: a478546a782a ("vsock/virtio: add support for listen sockets")
Reported-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
Signed-off-by: Divya Mankani <divyakm@unc.edu>
---
net/vmw_vsock/virtio_transport_common.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index 3b294164b..8006a13bb 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -1571,15 +1571,20 @@ virtio_transport_recv_listen(struct sock *sk, struct sk_buff *skb,
vsock_addr_init(&vchild->remote_addr, le64_to_cpu(hdr->src_cid),
le32_to_cpu(hdr->src_port));
- ret = vsock_assign_transport(vchild, vsk);
- /* Transport assigned (looking at remote_addr) must be the same
- * where we received the request.
+ /* Lock the parent listener socket to synchronize with a potential
+ * simultaneous shutdown thread running __vsock_release().
*/
- if (ret || vchild->transport != &t->transport) {
+ lock_sock(sk);
+
+ /* Check if the listener socket was shut down while we were
+ * creating and configuring the child socket.
+ */
+ if (sk->sk_shutdown == SHUTDOWN_MASK) {
+ release_sock(sk);
release_sock(child);
virtio_transport_reset_no_sock(t, skb, sock_net(sk));
sock_put(child);
- return ret;
+ return -ESHUTDOWN;
}
sk_acceptq_added(sk);
@@ -1590,6 +1595,8 @@ virtio_transport_recv_listen(struct sock *sk, struct sk_buff *skb,
vsock_enqueue_accept(sk, child);
virtio_transport_send_response(vchild, skb);
+ /* Safely release both locked objects */
+ release_sock(sk);
release_sock(child);
sk->sk_data_ready(sk);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen
2026-06-05 19:19 [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen Divya Mankani
@ 2026-06-06 7:19 ` kernel test robot
2026-06-06 14:24 ` [syzbot ci] " syzbot ci
1 sibling, 0 replies; 3+ messages in thread
From: kernel test robot @ 2026-06-06 7:19 UTC (permalink / raw)
To: Divya Mankani, kuba, pabeni
Cc: oe-kbuild-all, horms, virtualization, kvm, netdev, linux-kernel,
syzbot+1b2c9c4a0f8708082678, Divya Mankani
Hi Divya,
kernel test robot noticed the following build warnings:
[auto build test WARNING on mst-vhost/linux-next]
[also build test WARNING on linus/master v6.16-rc1 next-20260605]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Divya-Mankani/vsock-virtio-fix-memory-leak-in-virtio_transport_recv_listen/20260606-032557
base: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next
patch link: https://lore.kernel.org/r/20260605191922.12720-1-divyakm%40unc.edu
patch subject: [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen
config: s390-allnoconfig-bpf (https://download.01.org/0day-ci/archive/20260606/202606060907.y54Wngh6-lkp@intel.com/config)
compiler: s390x-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260606/202606060907.y54Wngh6-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606060907.y54Wngh6-lkp@intel.com/
All warnings (new ones prefixed by >>):
net/vmw_vsock/virtio_transport_common.c: In function 'virtio_transport_recv_listen':
>> net/vmw_vsock/virtio_transport_common.c:1538:13: warning: unused variable 'ret' [-Wunused-variable]
1538 | int ret;
| ^~~
>> net/vmw_vsock/virtio_transport_common.c:1535:28: warning: unused variable 'vsk' [-Wunused-variable]
1535 | struct vsock_sock *vsk = vsock_sk(sk);
| ^~~
vim +/ret +1538 net/vmw_vsock/virtio_transport_common.c
c0cfa2d8a788fc Stefano Garzarella 2019-11-14 1528
06a8fc78367d07 Asias He 2016-07-28 1529 /* Handle server socket */
06a8fc78367d07 Asias He 2016-07-28 1530 static int
71dc9ec9ac7d3e Bobby Eshleman 2023-01-13 1531 virtio_transport_recv_listen(struct sock *sk, struct sk_buff *skb,
c0cfa2d8a788fc Stefano Garzarella 2019-11-14 1532 struct virtio_transport *t)
06a8fc78367d07 Asias He 2016-07-28 1533 {
71dc9ec9ac7d3e Bobby Eshleman 2023-01-13 1534 struct virtio_vsock_hdr *hdr = virtio_vsock_hdr(skb);
06a8fc78367d07 Asias He 2016-07-28 @1535 struct vsock_sock *vsk = vsock_sk(sk);
06a8fc78367d07 Asias He 2016-07-28 1536 struct vsock_sock *vchild;
06a8fc78367d07 Asias He 2016-07-28 1537 struct sock *child;
c0cfa2d8a788fc Stefano Garzarella 2019-11-14 @1538 int ret;
06a8fc78367d07 Asias He 2016-07-28 1539
71dc9ec9ac7d3e Bobby Eshleman 2023-01-13 1540 if (le16_to_cpu(hdr->op) != VIRTIO_VSOCK_OP_REQUEST) {
a69686327e4291 Bobby Eshleman 2026-01-21 1541 virtio_transport_reset_no_sock(t, skb, sock_net(sk));
06a8fc78367d07 Asias He 2016-07-28 1542 return -EINVAL;
06a8fc78367d07 Asias He 2016-07-28 1543 }
06a8fc78367d07 Asias He 2016-07-28 1544
06a8fc78367d07 Asias He 2016-07-28 1545 if (sk_acceptq_is_full(sk)) {
a69686327e4291 Bobby Eshleman 2026-01-21 1546 virtio_transport_reset_no_sock(t, skb, sock_net(sk));
06a8fc78367d07 Asias He 2016-07-28 1547 return -ENOMEM;
06a8fc78367d07 Asias He 2016-07-28 1548 }
06a8fc78367d07 Asias He 2016-07-28 1549
d7b0ff5a866724 Michal Luczaj 2024-11-07 1550 /* __vsock_release() might have already flushed accept_queue.
d7b0ff5a866724 Michal Luczaj 2024-11-07 1551 * Subsequent enqueues would lead to a memory leak.
d7b0ff5a866724 Michal Luczaj 2024-11-07 1552 */
d7b0ff5a866724 Michal Luczaj 2024-11-07 1553 if (sk->sk_shutdown == SHUTDOWN_MASK) {
a69686327e4291 Bobby Eshleman 2026-01-21 1554 virtio_transport_reset_no_sock(t, skb, sock_net(sk));
d7b0ff5a866724 Michal Luczaj 2024-11-07 1555 return -ESHUTDOWN;
d7b0ff5a866724 Michal Luczaj 2024-11-07 1556 }
d7b0ff5a866724 Michal Luczaj 2024-11-07 1557
b9ca2f5ff7784d Stefano Garzarella 2019-11-14 1558 child = vsock_create_connected(sk);
06a8fc78367d07 Asias He 2016-07-28 1559 if (!child) {
a69686327e4291 Bobby Eshleman 2026-01-21 1560 virtio_transport_reset_no_sock(t, skb, sock_net(sk));
06a8fc78367d07 Asias He 2016-07-28 1561 return -ENOMEM;
06a8fc78367d07 Asias He 2016-07-28 1562 }
06a8fc78367d07 Asias He 2016-07-28 1563
06a8fc78367d07 Asias He 2016-07-28 1564 lock_sock_nested(child, SINGLE_DEPTH_NESTING);
06a8fc78367d07 Asias He 2016-07-28 1565
3b4477d2dcf270 Stefan Hajnoczi 2017-10-05 1566 child->sk_state = TCP_ESTABLISHED;
06a8fc78367d07 Asias He 2016-07-28 1567
06a8fc78367d07 Asias He 2016-07-28 1568 vchild = vsock_sk(child);
71dc9ec9ac7d3e Bobby Eshleman 2023-01-13 1569 vsock_addr_init(&vchild->local_addr, le64_to_cpu(hdr->dst_cid),
71dc9ec9ac7d3e Bobby Eshleman 2023-01-13 1570 le32_to_cpu(hdr->dst_port));
71dc9ec9ac7d3e Bobby Eshleman 2023-01-13 1571 vsock_addr_init(&vchild->remote_addr, le64_to_cpu(hdr->src_cid),
71dc9ec9ac7d3e Bobby Eshleman 2023-01-13 1572 le32_to_cpu(hdr->src_port));
06a8fc78367d07 Asias He 2016-07-28 1573
b09fac3ae8b655 Divya Mankani 2026-06-06 1574 /* Lock the parent listener socket to synchronize with a potential
b09fac3ae8b655 Divya Mankani 2026-06-06 1575 * simultaneous shutdown thread running __vsock_release().
c0cfa2d8a788fc Stefano Garzarella 2019-11-14 1576 */
b09fac3ae8b655 Divya Mankani 2026-06-06 1577 lock_sock(sk);
b09fac3ae8b655 Divya Mankani 2026-06-06 1578
b09fac3ae8b655 Divya Mankani 2026-06-06 1579 /* Check if the listener socket was shut down while we were
b09fac3ae8b655 Divya Mankani 2026-06-06 1580 * creating and configuring the child socket.
b09fac3ae8b655 Divya Mankani 2026-06-06 1581 */
b09fac3ae8b655 Divya Mankani 2026-06-06 1582 if (sk->sk_shutdown == SHUTDOWN_MASK) {
b09fac3ae8b655 Divya Mankani 2026-06-06 1583 release_sock(sk);
c0cfa2d8a788fc Stefano Garzarella 2019-11-14 1584 release_sock(child);
a69686327e4291 Bobby Eshleman 2026-01-21 1585 virtio_transport_reset_no_sock(t, skb, sock_net(sk));
c0cfa2d8a788fc Stefano Garzarella 2019-11-14 1586 sock_put(child);
b09fac3ae8b655 Divya Mankani 2026-06-06 1587 return -ESHUTDOWN;
c0cfa2d8a788fc Stefano Garzarella 2019-11-14 1588 }
c0cfa2d8a788fc Stefano Garzarella 2019-11-14 1589
52bcb57a4e8a08 Dudu Lu 2026-04-13 1590 sk_acceptq_added(sk);
71dc9ec9ac7d3e Bobby Eshleman 2023-01-13 1591 if (virtio_transport_space_update(child, skb))
c0cfa2d8a788fc Stefano Garzarella 2019-11-14 1592 child->sk_write_space(child);
c0cfa2d8a788fc Stefano Garzarella 2019-11-14 1593
06a8fc78367d07 Asias He 2016-07-28 1594 vsock_insert_connected(vchild);
06a8fc78367d07 Asias He 2016-07-28 1595 vsock_enqueue_accept(sk, child);
71dc9ec9ac7d3e Bobby Eshleman 2023-01-13 1596 virtio_transport_send_response(vchild, skb);
06a8fc78367d07 Asias He 2016-07-28 1597
b09fac3ae8b655 Divya Mankani 2026-06-06 1598 /* Safely release both locked objects */
b09fac3ae8b655 Divya Mankani 2026-06-06 1599 release_sock(sk);
06a8fc78367d07 Asias He 2016-07-28 1600 release_sock(child);
06a8fc78367d07 Asias He 2016-07-28 1601
06a8fc78367d07 Asias He 2016-07-28 1602 sk->sk_data_ready(sk);
06a8fc78367d07 Asias He 2016-07-28 1603 return 0;
06a8fc78367d07 Asias He 2016-07-28 1604 }
06a8fc78367d07 Asias He 2016-07-28 1605
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 3+ messages in thread* [syzbot ci] Re: vsock/virtio: fix memory leak in virtio_transport_recv_listen
2026-06-05 19:19 [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen Divya Mankani
2026-06-06 7:19 ` kernel test robot
@ 2026-06-06 14:24 ` syzbot ci
1 sibling, 0 replies; 3+ messages in thread
From: syzbot ci @ 2026-06-06 14:24 UTC (permalink / raw)
To: divyakm, divyakm, horms, kuba, kvm, linux-kernel, netdev, pabeni,
syzbot, virtualization
Cc: syzbot, syzkaller-bugs
syzbot ci has tested the following series
[v1] vsock/virtio: fix memory leak in virtio_transport_recv_listen
https://lore.kernel.org/all/20260605191922.12720-1-divyakm@unc.edu
* [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen
and found the following issue:
possible deadlock in virtio_transport_recv_listen
Full report is available here:
https://ci.syzbot.org/series/76f40e62-5a21-46d4-a636-10f0ec9c5040
***
possible deadlock in virtio_transport_recv_listen
tree: net-next
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net-next.git
base: bfa3d89cc15c09f7d1581c834a5ed725189ec19f
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/5a94a424-94b1-4b1e-8b06-74d59933368f/config
syz repro: https://ci.syzbot.org/findings/a8224003-11b3-4232-a635-6755ad892149/syz_repro
============================================
WARNING: possible recursive locking detected
syzkaller #0 Not tainted
--------------------------------------------
kworker/0:3/5740 is trying to acquire lock:
ffff88810efb62a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1713 [inline]
ffff88810efb62a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: virtio_transport_recv_listen+0x964/0x2120 net/vmw_vsock/virtio_transport_common.c:1577
but task is already holding lock:
ffff88810efb62a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1713 [inline]
ffff88810efb62a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: virtio_transport_recv_pkt+0xa26/0x2800 net/vmw_vsock/virtio_transport_common.c:1668
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(sk_lock-AF_VSOCK);
lock(sk_lock-AF_VSOCK);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by kworker/0:3/5740:
#0: ffff8881150d3540 ((wq_completion)vsock-loopback){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3289 [inline]
#0: ffff8881150d3540 ((wq_completion)vsock-loopback){+.+.}-{0:0}, at: process_scheduled_works+0xa35/0x1860 kernel/workqueue.c:3397
#1: ffffc90003fafc40 ((work_completion)(&vsock->pkt_work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3290 [inline]
#1: ffffc90003fafc40 ((work_completion)(&vsock->pkt_work)){+.+.}-{0:0}, at: process_scheduled_works+0xa70/0x1860 kernel/workqueue.c:3397
#2: ffff88810efb62a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1713 [inline]
#2: ffff88810efb62a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: virtio_transport_recv_pkt+0xa26/0x2800 net/vmw_vsock/virtio_transport_common.c:1668
#3: ffff88810efb5120 (sk_lock-AF_VSOCK/1){+.+.}-{0:0}, at: virtio_transport_recv_listen+0x83f/0x2120 net/vmw_vsock/virtio_transport_common.c:1564
stack backtrace:
CPU: 0 UID: 0 PID: 5740 Comm: kworker/0:3 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Workqueue: vsock-loopback vsock_loopback_work
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_deadlock_bug+0x279/0x290 kernel/locking/lockdep.c:3041
check_deadlock kernel/locking/lockdep.c:3093 [inline]
validate_chain kernel/locking/lockdep.c:3895 [inline]
__lock_acquire+0x253f/0x2cf0 kernel/locking/lockdep.c:5237
lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5868
lock_sock_nested+0x41/0x100 net/core/sock.c:3790
lock_sock include/net/sock.h:1713 [inline]
virtio_transport_recv_listen+0x964/0x2120 net/vmw_vsock/virtio_transport_common.c:1577
virtio_transport_recv_pkt+0x1570/0x2800 net/vmw_vsock/virtio_transport_common.c:1692
vsock_loopback_work+0x32c/0x3f0 net/vmw_vsock/vsock_loopback.c:142
process_one_work kernel/workqueue.c:3314 [inline]
process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3397
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3478
kthread+0x389/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).
The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-06-06 14:24 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-05 19:19 [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen Divya Mankani
2026-06-06 7:19 ` kernel test robot
2026-06-06 14:24 ` [syzbot ci] " syzbot ci
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox