GHSA-CF52-4QC8-H2H9

Vulnerability from github – Published: 2026-10-23 15:31 – Updated: 2026-10-23 15:31
VLAI
Details

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.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-98947"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-23T13:17:15Z",
    "severity": null
  },
  "details": "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\u0027s backlog; then, after the receive queue is cleared,\nthe __release_sock() function will move the packet back from the socket\u0027s\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(\u0026sk-\u003esk_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-\u003esk_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.\u0026.....x.\u0026.....\n    00 00 00 00 00 00 00 00 c0 da 26 1e 80 88 ff ff  ..........\u0026.....\n  backtrace:\n    [\u003cffffffff82be8d97\u003e] __alloc_skb+0x287/0x330 net/core/skbuff.c:505\n    [\u003cffffffffa114bcbd\u003e] vmci_transport_recv_dgram_cb+0xbd/0x210 [vmw_vsock_vmci_transport]\n    [\u003cffffffffa05072c6\u003e] vmci_datagram_invoke_guest_handler+0x366/0x450 [vmw_vmci]\n    [\u003cffffffffa050ad75\u003e] vmci_dispatch_dgs+0x235/0x490 [vmw_vmci]\n    [\u003cffffffffa050b025\u003e] vmci_interrupt+0x55/0x290 [vmw_vmci]\n    [\u003cffffffff8137ad2b\u003e] irq_thread_fn+0x8b/0x1a0 kernel/irq/manage.c:1205\n    [\u003cffffffff8137c7ae\u003e] irq_thread+0x28e/0x530 kernel/irq/manage.c:1314\n    [\u003cffffffff81253dd6\u003e] kthread+0x2e6/0x3a0 kernel/kthread.c:376\n    [\u003cffffffff81004392\u003e] 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.",
  "id": "GHSA-cf52-4qc8-h2h9",
  "modified": "2026-10-23T15:31:32Z",
  "published": "2026-10-23T15:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98947"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0f8e2b2045355a0ee2008125e573435504b13cee"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4835dbcde5cc3ae37e0d0796052056b35fcae8bf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7c24a4e87e219072e5e106f6791146cbf3b056b3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9907db2b8e7ba70b442bb9dec86526a6511fac62"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.