"value":"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 [<ffffffff81418ff1>] kmem_cache_alloc_noprof+0x2c1/0x360\n [<ffffffff81d27aa0>] sk_prot_alloc+0x30/0x120\n [<ffffffff81d2b54c>] sk_alloc+0x2c/0x4b0\n [<ffffffff81fe049a>] __vsock_create.constprop.0+0x2a/0x310\n [<ffffffff81fe6d6c>] virtio_transport_recv_pkt+0x4dc/0x9a0\n [<ffffffff81fe745d>] vsock_loopback_work+0xfd/0x140\n [<ffffffff810fc6ac>] process_one_work+0x20c/0x570\n [<ffffffff810fce3f>] worker_thread+0x1bf/0x3a0\n [<ffffffff811070dd>] kthread+0xdd/0x110\n [<ffffffff81044fdd>] ret_from_fork+0x2d/0x50\n [<ffffffff8100785a>] ret_from_fork_asm+0x1a/0x30"
"value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio/vsock: Se soluciona la p\u00e9rdida de memoria de accept_queue. Como las etapas finales de la destrucci\u00f3n del socket pueden demorarse, es posible que se llame a virtio_transport_recv_listen() despu\u00e9s de que se haya vaciado accept_queue, pero antes de que se haya establecido el indicador SOCK_DONE. Como resultado, los sockets en cola despu\u00e9s del vaciado permanecer\u00edan sin eliminar, lo que provocar\u00eda una p\u00e9rdida de memoria. vsock_release __vsock_release bloquear virtio_transport_release virtio_transport_close schedule_delayed_work(cerrar_trabajo) sk_shutdown = SHUTDOWN_MASK (!) vaciar accept_queue liberar virtio_transport_recv_pkt vsock_find_bound_socket bloquear si indicador(SOCK_DONE) devolver virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) liberar close_work bloquear virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound liberar Introduce una comprobaci\u00f3n de sk_shutdown para no permitir vsock_enqueue_accept() durante la destrucci\u00f3n del socket. objeto sin referencia 0xffff888109e3f800 (tama\u00f1o 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 volcado hexadecimal (primeros 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 [] subproceso_trabajador+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_de_la_bifurcaci\u00f3n+0x2d/0x50 [] ret_de_la_bifurcaci\u00f3n_asm+0x1a/0x30"
