--- id: "CVE-2026-98947" kind: "vulnerability" aliases: ["CVE-2026-98947"] title: "Linux kernel: vsock datagram close leaks memory from socket backlog" severity: "unknown" cvss: null epss: 0.00209 exploited: false status: "open" category: "infrastructure" products: [] ecosystems: [] tags: ["infrastructure", "kernel", "linux", "vmware", "vsock"] not_affected_if: ["no-vmci-transport"] published_at: "2026-10-23T13:17:15+00:00" first_seen_at: "2026-10-23T21:57:33+00:00" updated_at: "2026-10-25T12:38:50+00:00" sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98947", "first_seen_at": "2026-10-23T21:57:33+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-98947", "first_seen_at": "2026-10-25T12:38:50+00:00"}] --- # Linux kernel: vsock datagram close leaks memory from socket backlog When a vsock datagram socket is closed, packets that arrived during closure can be moved back into the receive queue after it was cleared, so the memory is never freed. The sources describe a memory leak, not a way for an attacker to run code or read data. _Summary, check and fix written by a model from the sources; labelled as such._ ## How to check - Check the running kernel with `uname -r` and whether the `vmw_vsock_vmci_transport` module is loaded with `lsmod | grep vmw_vsock_vmci` - Only VMware VMCI-based vsock guests or hosts load this module; unknown whether other setups are affected ## Fix - Update to a Linux kernel build that includes the upstream commit adding a receive queue cleanup in the socket destructor (version unknown from the sources) ## Timeline - 2026-10-23T21:57:33+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98947 - 2026-10-25T12:38:50+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-98947 ## From the sources In the Linux kernel, the following vulnerability has been resolved: vsock: Fix memory leak in vmci_transport_recv_dgram_cb() During the closure of a datagram socket, the vmci_transport_recv_dgram_cb() function may be called, which will add the packets to the socket's backlog; then, after the receive queue is cleared, the __release_sock() function will move the packet back from the socket's backlog to the receive queue, which will lead to a memory leak. sock_close __sock_release __vsock_release // take ownership by user-space lock_sock_nested sock_set_flag(sk, SOCK_DEAD) vmci_transport_release vmci_dispatch_dgs vmci_datagram_invoke_guest_handler vmci_transport_recv_dgram_cb sk_receive_skb if (!sock_owned_by_user(sk)) [...] (!) else if sk_add_backlog() [...] (!) skb_queue_purge(&sk->sk_receive_queue) release_sock __release_sock // move all packets from the backlog // to the receive queue (!) sk_backlog_rcv vsock_queue_rcv_skb [...] __sock_queue_rcv_skb if (!sock_flag(sk, SOCK_DEAD)) // Since the socket is "dead", the function will not // be called sk->sk_data_ready(sk) sock_release_ownership(sk); sock_put Add a receive queue cleanup in the socket destructor to fix this. syzkaller report: unreferenced object 0xffff8880117bfb80 (size 240): comm "irq/56-vmw_vmci", pid 205, jiffies 4295064448 (age 73.992s) hex dump (first 32 bytes): 78 dc 26 1e 80 88 ff ff 78 dc 26 1e 80 88 ff ff x.&.....x.&..... 00 00 00 00 00 00 00 00 c0 da 26 1e 80 88 ff ff ..........&..... backtrace: [] __alloc_skb+0x287/0x330 net/core/skbuff.c:505 [] vmci_transport_recv_dgram_cb+0xbd/0x210 [vmw_vsock_vmci_transport] [] vmci_datagram_invoke_guest_handler+0x366/0x450 [vmw_vmci] [] vmci_dispatch_dgs+0x235/0x490 [vmw_vmci] [] vmci_interrupt+0x55/0x290 [vmw_vmci] [] irq_thread_fn+0x8b/0x1a0 kernel/irq/manage.c:1205 [] irq_thread+0x28e/0x530 kernel/irq/manage.c:1314 [] kthread+0x2e6/0x3a0 kernel/kthread.c:376 [] ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:295 Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller. --- _Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_