CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-53119 – virtio/vsock: Fix accept_queue memory leak
https://notcve.org/view.php?id=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): [<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/e26fa236758e8baa61a82cfd9fd4388d2e8d6a4c https://git.kernel.org/stable/c/4310902c766e371359e6c6311056ae80b5beeac9 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/d7b0ff5a866724c3ad21f2628c22a6333 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53114 – x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client
https://notcve.org/view.php?id=CVE-2024-53114
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 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-53113 – mm: fix NULL pointer dereference in alloc_pages_bulk_noprof
https://notcve.org/view.php?id=CVE-2024-53113
In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 ("mm, page_alloc: fix check for NULL preferred_zone") and commit df76cee6bbeb ("mm, page_alloc: remove redundant checks from alloc fastpath"). To fix it, check NULL pointer for preferred_zoneref->zone. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: corregir la desreferencia de puntero NULL en alloc_pages_bulk_noprof Activamos una desreferencia de puntero NULL para ac.preferred_zoneref->zone en alloc_pages_bulk_noprof() cuando la tarea se migra entre conjuntos de CPU. • https://git.kernel.org/stable/c/387ba26fb1cb9be9e35dc14a6d97188e916eda05 https://git.kernel.org/stable/c/903d896448c2e50e8652aaba529a30d4d1eaa0e5 https://git.kernel.org/stable/c/6addb2d9501ec866d7b3a3b4e665307c437e9be2 https://git.kernel.org/stable/c/d0f16cec79774c3132df006cf771eddd89d08f58 https://git.kernel.org/stable/c/31502374627ba9ec3e710dbd0bb00457cc6d2c19 https://git.kernel.org/stable/c/8ce41b0f9d77cca074df25afd39b86e2ee3aa68e •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-53112 – ocfs2: uncache inode which has failed entering the group
https://notcve.org/view.php?id=CVE-2024-53112
In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: <TASK> ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? • https://git.kernel.org/stable/c/7909f2bf835376a20d6dbf853eb459a27566eba2 https://git.kernel.org/stable/c/ac0cfe8ac35cf1be54131b90d114087b558777ca https://git.kernel.org/stable/c/5ae8cc0b0c027e9cab22596049bc4dd1cbc37ee4 https://git.kernel.org/stable/c/28d4ed71ae0b4baedca3e85ee6d8f227ec75ebf6 https://git.kernel.org/stable/c/0e04746db2ec4aec04cef5763b9d9aa32829ae2f https://git.kernel.org/stable/c/620d22598110b0d0cb97a3fcca65fc473ea86e73 https://git.kernel.org/stable/c/843dfc804af4b338ead42331dd58081b428ecdf8 https://git.kernel.org/stable/c/b751c50e19d66cfb7360c0b55cf17b072 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-53108 – drm/amd/display: Adjust VSDB parser for replay feature
https://notcve.org/view.php?id=CVE-2024-53108
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Ajustar el analizador VSDB para la función de reproducción En algún momento, se agregó la identificación IEEE ID para la comprobación de reproducción en AMD EDID. Sin embargo, esta comprobación provoca los siguientes problemas fuera de límites al utilizar KASAN: [ 27.804016] ERROR: KASAN: slab-out-of-bounds en amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Lectura de tamaño 1 en la dirección ffff8881647fdb00 por la tarea systemd-udevd/383 ... [ 27.821207] Estado de la memoria alrededor de la dirección con errores: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ===================================================================== Esto se debe a que la extracción de ID se realiza fuera del rango de longitud de edid. Esta confirmación soluciona este problema al considerar el tamaño de amd_vsdb_block. • https://git.kernel.org/stable/c/0a326fbc8f72a320051f27328d4d4e7abdfe68d7 https://git.kernel.org/stable/c/8db867061f4c76505ad62422b65d666b45289217 https://git.kernel.org/stable/c/16dd2825c23530f2259fc671960a3a65d2af69bd •