GHSA-96GV-MMP8-MQX5
Vulnerability from github – Published: 2024-12-02 15:31 – Updated: 2025-11-04 00:32In the Linux kernel, the following vulnerability has been resolved:
virtio/vsock: Fix accept_queue memory leak
As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak.
vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release
Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction.
unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 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 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30
{
"affected": [],
"aliases": [
"CVE-2024-53119"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-02T14:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio/vsock: Fix accept_queue memory leak\n\nAs the final stages of socket destruction may be delayed, it is possible\nthat virtio_transport_recv_listen() will be called after the accept_queue\nhas been flushed, but before the SOCK_DONE flag has been set. As a result,\nsockets enqueued after the flush would remain unremoved, leading to a\nmemory leak.\n\nvsock_release\n __vsock_release\n lock\n virtio_transport_release\n virtio_transport_close\n schedule_delayed_work(close_work)\n sk_shutdown = SHUTDOWN_MASK\n(!) flush accept_queue\n release\n virtio_transport_recv_pkt\n vsock_find_bound_socket\n lock\n if flag(SOCK_DONE) return\n virtio_transport_recv_listen\n child = vsock_create_connected\n (!) vsock_enqueue_accept(child)\n release\nclose_work\n lock\n virtio_transport_do_close\n set_flag(SOCK_DONE)\n virtio_transport_remove_sock\n vsock_remove_sock\n vsock_remove_bound\n release\n\nIntroduce a sk_shutdown check to disallow vsock_enqueue_accept() during\nsocket destruction.\n\nunreferenced object 0xffff888109e3f800 (size 2040):\n comm \"kworker/5:2\", pid 371, jiffies 4294940105\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............\n backtrace (crc 9e5f4e84):\n [\u003cffffffff81418ff1\u003e] kmem_cache_alloc_noprof+0x2c1/0x360\n [\u003cffffffff81d27aa0\u003e] sk_prot_alloc+0x30/0x120\n [\u003cffffffff81d2b54c\u003e] sk_alloc+0x2c/0x4b0\n [\u003cffffffff81fe049a\u003e] __vsock_create.constprop.0+0x2a/0x310\n [\u003cffffffff81fe6d6c\u003e] virtio_transport_recv_pkt+0x4dc/0x9a0\n [\u003cffffffff81fe745d\u003e] vsock_loopback_work+0xfd/0x140\n [\u003cffffffff810fc6ac\u003e] process_one_work+0x20c/0x570\n [\u003cffffffff810fce3f\u003e] worker_thread+0x1bf/0x3a0\n [\u003cffffffff811070dd\u003e] kthread+0xdd/0x110\n [\u003cffffffff81044fdd\u003e] ret_from_fork+0x2d/0x50\n [\u003cffffffff8100785a\u003e] ret_from_fork_asm+0x1a/0x30",
"id": "GHSA-96gv-mmp8-mqx5",
"modified": "2025-11-04T00:32:09Z",
"published": "2024-12-02T15:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53119"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2415345042245de7601dcc6eafdbe3a3dcc9e379"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4310902c766e371359e6c6311056ae80b5beeac9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/897617a413e0bf1c6380e3b34b2f28f450508549"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/946c7600fa2207cc8d3fbc86a518ec56f98a5813"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d7b0ff5a866724c3ad21f2628c22a63336deec3f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e26fa236758e8baa61a82cfd9fd4388d2e8d6a4c"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
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.