cve/2024/CVE-2024-53119.md

### [CVE-2024-53119](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-53119)
![](https://img.shields.io/static/v1?label=Product&message=Linux&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=2e7dd95046203bd05e8f4dc06ee53cace70a8e3c%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=3fe356d58efae54dade9ec94ea7c919ed20cf4db%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=5.10%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=blue)

### Description

In the Linux kernel, the following vulnerability has been resolved:virtio/vsock: Fix accept_queue memory leakAs the final stages of socket destruction may be delayed, it is possiblethat virtio_transport_recv_listen() will be called after the accept_queuehas been flushed, but before the SOCK_DONE flag has been set. As a result,sockets enqueued after the flush would remain unremoved, leading to amemory 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)                                          releaseclose_work  lock  virtio_transport_do_close    set_flag(SOCK_DONE)    virtio_transport_remove_sock      vsock_remove_sock        vsock_remove_bound  releaseIntroduce a sk_shutdown check to disallow vsock_enqueue_accept() duringsocket 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):    [<ffffffff81418ff1>] kmem_cache_alloc_noprof+0x2c1/0x360    [<ffffffff81d27aa0>] sk_prot_alloc+0x30/0x120    [<ffffffff81d2b54c>] sk_alloc+0x2c/0x4b0    [<ffffffff81fe049a>] __vsock_create.constprop.0+0x2a/0x310    [<ffffffff81fe6d6c>] virtio_transport_recv_pkt+0x4dc/0x9a0    [<ffffffff81fe745d>] vsock_loopback_work+0xfd/0x140    [<ffffffff810fc6ac>] process_one_work+0x20c/0x570    [<ffffffff810fce3f>] worker_thread+0x1bf/0x3a0    [<ffffffff811070dd>] kthread+0xdd/0x110    [<ffffffff81044fdd>] ret_from_fork+0x2d/0x50    [<ffffffff8100785a>] ret_from_fork_asm+0x1a/0x30

### POC

#### Reference
No PoCs from references.

#### Github
- https://github.com/w4zu/Debian_security