public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [syzbot] [virt?] [net?] memory leak in __vsock_create (2)
@ 2026-04-24  2:02 syzbot
  2026-04-24  5:18 ` Forwarded: [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen() syzbot
  0 siblings, 1 reply; 2+ messages in thread
From: syzbot @ 2026-04-24  2:02 UTC (permalink / raw)
  To: davem, edumazet, horms, kuba, linux-kernel, netdev, pabeni,
	sgarzare, syzkaller-bugs, virtualization

Hello,

syzbot found the following issue on:

HEAD commit:    1f318b96cc84 Linux 7.0-rc3
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14db28ba580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=2c6ad6fefffa76b1
dashboard link: https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12db28ba580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1215175a580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/d4ebd240d832/disk-1f318b96.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/9548f49a7dec/vmlinux-1f318b96.xz
kernel image: https://storage.googleapis.com/syzbot-assets/4e16f2bcfc7d/bzImage-1f318b96.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com

2026/03/09 23:37:29 executed programs: 5
BUG: memory leak
unreferenced object 0xffff888128bb6d00 (size 1272):
  comm "kworker/0:1", pid 10, jiffies 4294944453
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00  (..@............
  backtrace (crc 31367ed9):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4547 [inline]
    slab_alloc_node mm/slub.c:4869 [inline]
    kmem_cache_alloc_noprof+0x372/0x480 mm/slub.c:4876
    sk_prot_alloc+0x3e/0x1b0 net/core/sock.c:2239
    sk_alloc+0x36/0x460 net/core/sock.c:2301
    __vsock_create.constprop.0+0x38/0x2f0 net/vmw_vsock/af_vsock.c:893
    virtio_transport_recv_listen net/vmw_vsock/virtio_transport_common.c:1557 [inline]
    virtio_transport_recv_pkt+0x855/0xfc0 net/vmw_vsock/virtio_transport_common.c:1685
    vsock_loopback_work+0x104/0x140 net/vmw_vsock/vsock_loopback.c:142
    process_one_work+0x26c/0x5d0 kernel/workqueue.c:3275
    process_scheduled_works kernel/workqueue.c:3358 [inline]
    worker_thread+0x243/0x490 kernel/workqueue.c:3439
    kthread+0x14e/0x1a0 kernel/kthread.c:436
    ret_from_fork+0x23c/0x4b0 arch/x86/kernel/process.c:158
    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

BUG: memory leak
unreferenced object 0xffff8881141e93a0 (size 32):
  comm "kworker/0:1", pid 10, jiffies 4294944453
  hex dump (first 32 bytes):
    f8 6e 0a 00 81 88 ff ff 00 00 00 00 00 00 00 00  .n..............
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc e7f5c8b3):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4547 [inline]
    slab_alloc_node mm/slub.c:4869 [inline]
    __do_kmalloc_node mm/slub.c:5262 [inline]
    __kmalloc_noprof+0x3bd/0x560 mm/slub.c:5275
    kmalloc_noprof include/linux/slab.h:954 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    lsm_blob_alloc+0x4d/0x80 security/security.c:192
    lsm_sock_alloc security/security.c:4375 [inline]
    security_sk_alloc+0x2d/0x290 security/security.c:4391
    sk_prot_alloc+0x8f/0x1b0 net/core/sock.c:2248
    sk_alloc+0x36/0x460 net/core/sock.c:2301
    __vsock_create.constprop.0+0x38/0x2f0 net/vmw_vsock/af_vsock.c:893
    virtio_transport_recv_listen net/vmw_vsock/virtio_transport_common.c:1557 [inline]
    virtio_transport_recv_pkt+0x855/0xfc0 net/vmw_vsock/virtio_transport_common.c:1685
    vsock_loopback_work+0x104/0x140 net/vmw_vsock/vsock_loopback.c:142
    process_one_work+0x26c/0x5d0 kernel/workqueue.c:3275
    process_scheduled_works kernel/workqueue.c:3358 [inline]
    worker_thread+0x243/0x490 kernel/workqueue.c:3439
    kthread+0x14e/0x1a0 kernel/kthread.c:436
    ret_from_fork+0x23c/0x4b0 arch/x86/kernel/process.c:158
    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

BUG: memory leak
unreferenced object 0xffff888128bfa8a0 (size 96):
  comm "kworker/0:1", pid 10, jiffies 4294944453
  hex dump (first 32 bytes):
    00 6d bb 28 81 88 ff ff 00 00 00 00 00 00 00 00  .m.(............
    00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00  ................
  backtrace (crc 1fd60988):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4547 [inline]
    slab_alloc_node mm/slub.c:4869 [inline]
    __kmalloc_cache_noprof+0x377/0x480 mm/slub.c:5378
    kmalloc_noprof include/linux/slab.h:950 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    virtio_transport_do_socket_init+0x2b/0xf0 net/vmw_vsock/virtio_transport_common.c:923
    vsock_assign_transport+0x309/0x3a0 net/vmw_vsock/af_vsock.c:642
    virtio_transport_recv_listen net/vmw_vsock/virtio_transport_common.c:1575 [inline]
    virtio_transport_recv_pkt+0x8bc/0xfc0 net/vmw_vsock/virtio_transport_common.c:1685
    vsock_loopback_work+0x104/0x140 net/vmw_vsock/vsock_loopback.c:142
    process_one_work+0x26c/0x5d0 kernel/workqueue.c:3275
    process_scheduled_works kernel/workqueue.c:3358 [inline]
    worker_thread+0x243/0x490 kernel/workqueue.c:3439
    kthread+0x14e/0x1a0 kernel/kthread.c:436
    ret_from_fork+0x23c/0x4b0 arch/x86/kernel/process.c:158
    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

BUG: memory leak
unreferenced object 0xffff888129e1e800 (size 1272):
  comm "kworker/1:3", pid 5832, jiffies 4294944454
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00  (..@............
  backtrace (crc 4bfb7c57):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4547 [inline]
    slab_alloc_node mm/slub.c:4869 [inline]
    kmem_cache_alloc_noprof+0x372/0x480 mm/slub.c:4876
    sk_prot_alloc+0x3e/0x1b0 net/core/sock.c:2239
    sk_alloc+0x36/0x460 net/core/sock.c:2301
    __vsock_create.constprop.0+0x38/0x2f0 net/vmw_vsock/af_vsock.c:893
    virtio_transport_recv_listen net/vmw_vsock/virtio_transport_common.c:1557 [inline]
    virtio_transport_recv_pkt+0x855/0xfc0 net/vmw_vsock/virtio_transport_common.c:1685
    vsock_loopback_work+0x104/0x140 net/vmw_vsock/vsock_loopback.c:142
    process_one_work+0x26c/0x5d0 kernel/workqueue.c:3275
    process_scheduled_works kernel/workqueue.c:3358 [inline]
    worker_thread+0x243/0x490 kernel/workqueue.c:3439
    kthread+0x14e/0x1a0 kernel/kthread.c:436
    ret_from_fork+0x23c/0x4b0 arch/x86/kernel/process.c:158
    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

BUG: memory leak
unreferenced object 0xffff888114372e80 (size 32):
  comm "kworker/1:3", pid 5832, jiffies 4294944454
  hex dump (first 32 bytes):
    f8 6e 0a 00 81 88 ff ff 00 00 00 00 00 00 00 00  .n..............
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc e7f5c8b3):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4547 [inline]
    slab_alloc_node mm/slub.c:4869 [inline]
    __do_kmalloc_node mm/slub.c:5262 [inline]
    __kmalloc_noprof+0x3bd/0x560 mm/slub.c:5275
    kmalloc_noprof include/linux/slab.h:954 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    lsm_blob_alloc+0x4d/0x80 security/security.c:192
    lsm_sock_alloc security/security.c:4375 [inline]
    security_sk_alloc+0x2d/0x290 security/security.c:4391
    sk_prot_alloc+0x8f/0x1b0 net/core/sock.c:2248
    sk_alloc+0x36/0x460 net/core/sock.c:2301
    __vsock_create.constprop.0+0x38/0x2f0 net/vmw_vsock/af_vsock.c:893
    virtio_transport_recv_listen net/vmw_vsock/virtio_transport_common.c:1557 [inline]
    virtio_transport_recv_pkt+0x855/0xfc0 net/vmw_vsock/virtio_transport_common.c:1685
    vsock_loopback_work+0x104/0x140 net/vmw_vsock/vsock_loopback.c:142
    process_one_work+0x26c/0x5d0 kernel/workqueue.c:3275
    process_scheduled_works kernel/workqueue.c:3358 [inline]
    worker_thread+0x243/0x490 kernel/workqueue.c:3439
    kthread+0x14e/0x1a0 kernel/kthread.c:436
    ret_from_fork+0x23c/0x4b0 arch/x86/kernel/process.c:158
    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

BUG: memory leak
unreferenced object 0xffff8881054d0ea0 (size 96):
  comm "kworker/1:3", pid 5832, jiffies 4294944454
  hex dump (first 32 bytes):
    00 e8 e1 29 81 88 ff ff 00 00 00 00 00 00 00 00  ...)............
    00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00  ................
  backtrace (crc 72501265):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4547 [inline]
    slab_alloc_node mm/slub.c:4869 [inline]
    __kmalloc_cache_noprof+0x377/0x480 mm/slub.c:5378
    kmalloc_noprof include/linux/slab.h:950 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    virtio_transport_do_socket_init+0x2b/0xf0 net/vmw_vsock/virtio_transport_common.c:923
    vsock_assign_transport+0x309/0x3a0 net/vmw_vsock/af_vsock.c:642
    virtio_transport_recv_listen net/vmw_vsock/virtio_transport_common.c:1575 [inline]
    virtio_transport_recv_pkt+0x8bc/0xfc0 net/vmw_vsock/virtio_transport_common.c:1685
    vsock_loopback_work+0x104/0x140 net/vmw_vsock/vsock_loopback.c:142
    process_one_work+0x26c/0x5d0 kernel/workqueue.c:3275
    process_scheduled_works kernel/workqueue.c:3358 [inline]
    worker_thread+0x243/0x490 kernel/workqueue.c:3439
    kthread+0x14e/0x1a0 kernel/kthread.c:436
    ret_from_fork+0x23c/0x4b0 arch/x86/kernel/process.c:158
    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

connection error: failed to recv *flatrpc.ExecutorMessageRawT: EOF


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Forwarded: [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen()
  2026-04-24  2:02 [syzbot] [virt?] [net?] memory leak in __vsock_create (2) syzbot
@ 2026-04-24  5:18 ` syzbot
  0 siblings, 0 replies; 2+ messages in thread
From: syzbot @ 2026-04-24  5:18 UTC (permalink / raw)
  To: linux-kernel, syzkaller-bugs

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 <kartikey406@gmail.com>
---
 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


^ permalink raw reply related	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-04-24  5:18 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-24  2:02 [syzbot] [virt?] [net?] memory leak in __vsock_create (2) syzbot
2026-04-24  5:18 ` Forwarded: [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen() syzbot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox