Page 2 of 3421 results (0.002 seconds)

CVSS: -EPSS: %CPEs: 5EXPL: 0

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): [<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 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio/vsock: Se soluciona la pérdida de memoria de accept_queue. Como las etapas finales de la destrucción del socket pueden demorarse, es posible que se llame a virtio_transport_recv_listen() después de que se haya vaciado accept_queue, pero antes de que se haya establecido el indicador SOCK_DONE. • https://git.kernel.org/stable/c/3fe356d58efae54dade9ec94ea7c919ed20cf4db https://git.kernel.org/stable/c/2e7dd95046203bd05e8f4dc06ee53cace70a8e3c https://git.kernel.org/stable/c/946c7600fa2207cc8d3fbc86a518ec56f98a5813 https://git.kernel.org/stable/c/897617a413e0bf1c6380e3b34b2f28f450508549 https://git.kernel.org/stable/c/2415345042245de7601dcc6eafdbe3a3dcc9e379 https://git.kernel.org/stable/c/d7b0ff5a866724c3ad21f2628c22a63336deec3f •

CVSS: -EPSS: %CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm "vsock_test", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [<ffffffff81418ef7>] kmem_cache_alloc_node_noprof+0x2f7/0x370 [<ffffffff81d35882>] __alloc_skb+0x132/0x180 [<ffffffff81d2d32b>] sock_omalloc+0x4b/0x80 [<ffffffff81d3a8ae>] msg_zerocopy_realloc+0x9e/0x240 [<ffffffff81fe5cb2>] virtio_transport_send_pkt_info+0x412/0x4c0 [<ffffffff81fe6183>] virtio_transport_stream_enqueue+0x43/0x50 [<ffffffff81fe0813>] vsock_connectible_sendmsg+0x373/0x450 [<ffffffff81d233d5>] ____sys_sendmsg+0x365/0x3a0 [<ffffffff81d246f4>] ___sys_sendmsg+0x84/0xd0 [<ffffffff81d26f47>] __sys_sendmsg+0x47/0x80 [<ffffffff820d3df3>] do_syscall_64+0x93/0x180 [<ffffffff8220012b>] entry_SYSCALL_64_after_hwframe+0x76/0x7e En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vsock: se corrige la pérdida de memoria sk_error_queue. El kernel coloca en cola las notificaciones de finalización MSG_ZEROCOPY en la cola de errores, donde permanecen hasta que se recv()en forma explícita. • https://git.kernel.org/stable/c/581512a6dc939ef122e49336626ae159f3b8a345 https://git.kernel.org/stable/c/bea4779a45f49275b1e1b1bd9de03cd3727244d8 https://git.kernel.org/stable/c/fbf7085b3ad1c7cc0677834c90f985f1b4f77a33 •

CVSS: -EPSS: %CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio/vsock: Mejorar el manejo de errores MSG_ZEROCOPY. Agregar un kfree_skb() faltante para evitar pérdidas de memoria. • https://git.kernel.org/stable/c/581512a6dc939ef122e49336626ae159f3b8a345 https://git.kernel.org/stable/c/50061d7319e21165d04e3024354c1b43b6137821 https://git.kernel.org/stable/c/60cf6206a1f513512f5d73fa4d3dbbcad2e7dcd6 •

CVSS: -EPSS: %CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 <snip> pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 <snip> Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 <snip> panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] <snip> pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] <snip> panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panthor: Corregir el manejo del mapeo parcial de la GPU de los BO. Esta confirmación corrige el error en el manejo del mapeo parcial de los objetos del búfer a la GPU, que causaba advertencias del kernel. Panthor no manejaba correctamente el caso en el que el mapeo parcial abarcaba múltiples listas de dispersión y el desplazamiento del mapeo no apuntaba a la primera página de la lista de dispersión inicial. • https://git.kernel.org/stable/c/647810ec247641eb5aec8caef818919a4518a0b1 https://git.kernel.org/stable/c/d3e61af64b770e0038470c81f42bd1d0598f6bcc https://git.kernel.org/stable/c/3387e043918e154ca08d83954966a8b087fe2835 •

CVSS: -EPSS: %CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/CPU/AMD: Borrar VMLOAD/VMSAVE virtualizado en el cliente Zen4 Varios SoC de cliente Zen4 anuncian la capacidad de usar VMLOAD/VMSAVE virtualizado, pero se informa que el uso de estas instrucciones es la causa de un reinicio aleatorio del host. Estas instrucciones no están destinadas a ser anunciadas en el cliente Zen4, por lo que se debe borrar la capacidad. • https://git.kernel.org/stable/c/00c713f84f477a85e524f34aad8fbd11a1c051f0 https://git.kernel.org/stable/c/a5ca1dc46a6b610dd4627d8b633d6c84f9724ef0 •