5.5 - CVE-2024-53119

In 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