{"id":"CVE-2026-98947","kind":"vulnerability","aliases":["CVE-2026-98947"],"related":[],"title":"Linux kernel: vsock datagram close leaks memory from socket backlog","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nvsock: Fix memory leak in vmci_transport_recv_dgram_cb()\n\nDuring the closure of a datagram socket, the vmci_transport_recv_dgram_cb()\nfunction may be called, which will add the packets\nto the socket's backlog; then, after the receive queue is cleared,\nthe __release_sock() function will move the packet back from the socket's\nbacklog to the receive queue, which will lead to a memory leak.\n\nsock_close\n  __sock_release\n    __vsock_release\n      // take ownership by user-space\n      lock_sock_nested\n      sock_set_flag(sk, SOCK_DEAD)\n      vmci_transport_release\n                                      vmci_dispatch_dgs\n                                        vmci_datagram_invoke_guest_handler\n                                          vmci_transport_recv_dgram_cb\n                                            sk_receive_skb\n                                              if (!sock_owned_by_user(sk))\n                                                  [...]\n                                         (!)  else if sk_add_backlog()\n                                                  [...]\n  (!) skb_queue_purge(&sk->sk_receive_queue)\n\n      release_sock\n        __release_sock\n          // move all packets from the backlog\n          // to the receive queue\n   (!)    sk_backlog_rcv\n            vsock_queue_rcv_skb\n            [...]\n              __sock_queue_rcv_skb\n                if (!sock_flag(sk, SOCK_DEAD))\n                  // Since the socket is \"dead\", the function will not\n                  // be called\n                  sk->sk_data_ready(sk)\n        sock_release_ownership(sk);\n        sock_put\n\nAdd a receive queue cleanup in the socket destructor to fix this.\n\nsyzkaller report:\n\nunreferenced object 0xffff8880117bfb80 (size 240):\n  comm \"irq/56-vmw_vmci\", pid 205, jiffies 4295064448 (age 73.992s)\n  hex dump (first 32 bytes):\n    78 dc 26 1e 80 88 ff ff 78 dc 26 1e 80 88 ff ff  x.&.....x.&.....\n    00 00 00 00 00 00 00 00 c0 da 26 1e 80 88 ff ff  ..........&.....\n  backtrace:\n    [<ffffffff82be8d97>] __alloc_skb+0x287/0x330 net/core/skbuff.c:505\n    [<ffffffffa114bcbd>] vmci_transport_recv_dgram_cb+0xbd/0x210 [vmw_vsock_vmci_transport]\n    [<ffffffffa05072c6>] vmci_datagram_invoke_guest_handler+0x366/0x450 [vmw_vmci]\n    [<ffffffffa050ad75>] vmci_dispatch_dgs+0x235/0x490 [vmw_vmci]\n    [<ffffffffa050b025>] vmci_interrupt+0x55/0x290 [vmw_vmci]\n    [<ffffffff8137ad2b>] irq_thread_fn+0x8b/0x1a0 kernel/irq/manage.c:1205\n    [<ffffffff8137c7ae>] irq_thread+0x28e/0x530 kernel/irq/manage.c:1314\n    [<ffffffff81253dd6>] kthread+0x2e6/0x3a0 kernel/kthread.c:376\n    [<ffffffff81004392>] ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:295\n\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with Syzkaller.","summary":"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.","severity":"unknown","cvss":null,"epss":0.00209,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["infrastructure","kernel","linux","vmware","vsock"],"not_affected_if":["no-vmci-transport"],"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`\n- 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)","status":"open","published_at":"2026-10-23T13:17:15+00:00","first_seen_at":"2026-10-23T21:57:33+00:00","triaged_at":"2026-10-25T04:57:58+00:00","updated_at":"2026-10-25T12:38:50+00:00","category":"infrastructure","confidence":0.5,"triage":{"at":"2026-10-25T04:57:58Z","model":"claude-haiku-5-5","output":{"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)","reach":"local","title":"Linux kernel: vsock datagram close leaks memory from socket backlog","impact":"low","summary":"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.","category":"infrastructure","nicknames":[],"who_cares":["linux","kernel","vmware","vsock"],"confidence":0.5,"needs_auth":"unknown","worst_case":"Kernel memory leaks slowly when datagram sockets close; no code execution stated.","analyst_note":"Confirm affected kernel versions and the fixed stable release from the NVD entry or the upstream kernel commit.","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`\n- Only VMware VMCI-based vsock guests or hosts load this module; unknown whether other setups are affected","needs_analyst":true,"not_affected_if":["no-vmci-transport"],"who_is_affected":"Only systems that load the vmw_vsock_vmci_transport module, which is used with VMware VMCI virtual sockets. Hosts that do not use VMCI vsock can skip it. The sources do not name specific distributions or kernel versions.","user_interaction":"no","needs_special_setup":"yes","severity_if_unknown":"unknown"},"cost_usd":0.000734,"input_tokens":4446,"output_tokens":579,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'+0':330C,339C,350C,357C,363C,370C,376C,381C,388C '-2026':12A,15A '-98947':13A,16A '00':311C,312C,313C,314C,315C,316C,317C,318C '0xffff8880117bfb80':276C '1205':373C '1314':379C '1e':296C,304C,322C '205':282C '240':278C '26':295C,303C,321C '295':391C '32':291C '376':384C '4295064448':284C '505':333C '73.992':286C '78':293C,301C '80':297C,305C,323C '88':298C,306C,324C 'add':109C,198C,260C 'age':285C 'alloc':328C 'arch/x86/entry/entry_64.s':390C 'arriv':31B 'attack':63B 'back':37B,132C 'backlog':10A,116C,137C,199C,216C,222C 'backtrac':327C 'behalf':396C 'byte':292C 'c0':319C 'call':106C,248C 'cb':89C,102C,185C,338C 'center':400C 'cleanup':264C 'clear':45B,123C 'close':5A,28B,150C 'closur':33B,92C 'code':66B 'comm':279C 'cve':11A,14A 'da':320C 'data':69B,251C 'datagram':4A,25B,95C,177C,346C 'dc':294C,302C 'dead':169C,237C,242C 'describ':54B 'destructor':268C 'dgram':88C,101C,184C,337C 'dgs':175C,356C 'dispatch':174C,355C 'dump':289C 'els':195C 'ff':299C,300C,307C,308C,325C,326C 'first':290C 'fix':81C,270C 'flag':166C,234C 'fn':369C 'follow':75C 'fork':387C 'found':392C 'freed':51B 'function':103C,127C,244C 'guest':179C,348C 'handler':180C,349C 'hex':288C 'infotec':394C 'infrastructur':17B 'interrupt':362C 'invok':178C,347C 'irq':367C,374C 'irq/56-vmw_vmci':280C 'jiffi':283C 'kernel':2A,18B,73C 'kernel/irq/manage.c':372C,378C 'kernel/kthread.c':383C 'kthread':380C 'lead':144C 'leak':6A,57B,83C,148C 'linux':1A,19B,72C,398C 'linuxtesting.org':401C 'lock':161C 'may':104C 'memori':7A,48B,56B,82C,147C 'move':36B,129C,211C 'nest':163C 'net/core/skbuff.c':332C 'never':50B 'object':275C 'own':191C 'ownership':156C,256C 'packet':29B,111C,131C,213C 'pid':281C 'purg':202C 'put':259C 'queue':41B,121C,141C,201C,206C,220C,225C,229C,263C 'rcv':223C,226C,230C 'read':68B 'readi':252C 'receiv':40B,120C,140C,187C,205C,219C,262C 'recv':87C,100C,183C,336C 'releas':125C,152C,154C,172C,207C,209C,255C 'report':273C 'resolv':79C 'ret':385C 'run':65B 'set':165C 'sinc':238C 'size':277C 'sk':167C,186C,194C,197C,203C,204C,221C,235C,249C,250C,253C,257C 'skb':188C,200C,227C,231C,329C 'sock':126C,149C,151C,162C,164C,168C,190C,208C,210C,228C,233C,236C,254C,258C 'socket':9A,26B,96C,114C,135C,240C,267C 'sourc':53B 'space':160C 'syzkal':272C,403C 'take':155C 'thread':368C,375C 'transport':86C,99C,171C,182C,335C,344C 'unreferenc':274C 'user':159C,193C 'user-spac':158C 'verif':399C 'vmci':85C,98C,170C,173C,176C,181C,334C,343C,345C,353C,354C,360C,361C,366C 'vmw':341C,352C,359C,365C 'vmware':20B 'vsock':3A,21B,24B,80C,153C,224C,342C 'vulner':76C 'way':60B 'x':309C,310C 'x22/0x30':389C 'x235/0x490':358C 'x287/0x330':331C 'x28e/0x530':377C 'x2e6/0x3a0':382C 'x366/0x450':351C 'x55/0x290':364C 'x8b/0x1a0':371C 'xbd/0x210':340C","nicknames":[],"mitigations":[],"who_affected":"Only systems that load the vmw_vsock_vmci_transport module, which is used with VMware VMCI virtual sockets. Hosts that do not use VMCI vsock can skip it. The sources do not name specific distributions or kernel versions.","tier":"C","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-23T13:17:15+00:00","kev":null,"cvss_vector":null,"cvss_by":null,"poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-98947","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98947","severity":null,"published_at":"2026-10-23T13:17:15+00:00","modified_at":"2026-10-23T13:17:15+00:00","first_seen_at":"2026-10-23T21:57:33+00:00","fetched_at":"2026-10-23T22:29:03+00:00","note":null},{"source":"epss","external_id":"CVE-2026-98947","url":"https://api.first.org/data/v1/epss?cve=CVE-2026-98947","severity":null,"published_at":null,"modified_at":null,"first_seen_at":"2026-10-25T12:38:50+00:00","fetched_at":"2026-10-25T12:38:50+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}