CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26834 – netfilter: nft_flow_offload: release dst in case direct xmit path is used
https://notcve.org/view.php?id=CVE-2024-26834
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_flow_offload: release dst in case direct xmit path is used Direct xmit does not use it since it calls dev_queue_xmit() to send packets, hence it calls dst_release(). kmemleak reports: unreferenced object 0xffff88814f440900 (size 184): comm "softirq", pid 0, jiffies 4294951896 hex dump (first 32 bytes): 00 60 5b 04 81 88 ff ff 00 e6 e8 82 ff ff ff ff .`[............. 21 0b 50 82 ff ff ff ff 00 00 00 00 00 00 00 00 !.P............. backtrace (crc cb2bf5d6): [<000000003ee17107>] kmem_cache_alloc+0x286/0x340 [<0000000021a5de2c>] dst_alloc+0x43/0xb0 [<00000000f0671159>] rt_dst_alloc+0x2e/0x190 [<00000000fe5092c9>] __mkroute_output+0x244/0x980 [<000000005fb96fb0>] ip_route_output_flow+0xc0/0x160 [<0000000045367433>] nf_ip_route+0xf/0x30 [<0000000085da1d8e>] nf_route+0x2d/0x60 [<00000000d1ecd1cb>] nft_flow_route+0x171/0x6a0 [nft_flow_offload] [<00000000d9b2fb60>] nft_flow_offload_eval+0x4e8/0x700 [nft_flow_offload] [<000000009f447dbb>] expr_call_ops_eval+0x53/0x330 [nf_tables] [<00000000072e1be6>] nft_do_chain+0x17c/0x840 [nf_tables] [<00000000d0551029>] nft_do_chain_inet+0xa1/0x210 [nf_tables] [<0000000097c9d5c6>] nf_hook_slow+0x5b/0x160 [<0000000005eccab1>] ip_forward+0x8b6/0x9b0 [<00000000553a269b>] ip_rcv+0x221/0x230 [<00000000412872e5>] __netif_receive_skb_one_core+0xfe/0x110 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_flow_offload: libera dst en caso de que se use la ruta de xmit directa Direct xmit no la usa ya que llama a dev_queue_xmit() para enviar paquetes, por lo tanto llama a dst_release(). informes kmemleak: objeto sin referencia 0xffff88814f440900 (tamaño 184): comm "softirq", pid 0, jiffies 4294951896 volcado hexadecimal (primeros 32 bytes): 00 60 5b 04 81 88 ff ff 00 e6 e8 82 ff ff ff ff .`[.. ........... 21 0b 50 82 ff ff ff ff 00 00 00 00 00 00 00 00 !.P................. retroceso (crc cb2bf5d6): [ <000000003ee17107>] kmem_cache_alloc+0x286/0x340 [<0000000021a5de2c>] dst_alloc+0x43/0xb0 [<00000000f0671159>] rt_dst_alloc+0x2e/0x190 [<00000000fe50 92c9>] __mkroute_output+0x244/0x980 [<000000005fb96fb0>] ip_route_output_flow+0xc0/0x160 [ <0000000045367433>] nf_ip_route+0xf/0x30 [<0000000085da1d8e>] nf_route+0x2d/0x60 [<00000000d1ecd1cb>] nft_flow_route+0x171/0x6a0 [nft_flow_offload] 0000d9b2fb60>] nft_flow_offload_eval+0x4e8/0x700 [nft_flow_offload] [<000000009f447dbb>] expr_call_ops_eval+0x53/0x330 [nf_tables] [<00000000072e1be6>] nft_do_chain+0x17c/0x840 [nf_tables] [<00000000d0551029>] nft_do_chain_inet+0xa1/0x210 [nf_tables] [ <0000000097c9d5c6>] nf_hook_slow+0x5b/0x160 [<0000000005eccab1>] ip_forward +0x8b6/0x9b0 [<00000000553a269b>] ip_rcv+0x221/0x230 [<00000000412872e5>] __netif_receive_skb_one_core+0xfe/0x110 • https://git.kernel.org/stable/c/fa502c86566680ac62bc28ec883a069bf7a2aa5e https://git.kernel.org/stable/c/9256ab9232e35a16af9c30fa4e522e6d1bd3605a https://git.kernel.org/stable/c/2d17cf10179a7de6d8f0128168b84ad0b4a1863f https://git.kernel.org/stable/c/8762785f459be1cfe6fcf7285c123aad6a3703f0 https://git.kernel.org/stable/c/13b57b5cd591d5b22f9bbf047b2922967de411f3 https://git.kernel.org/stable/c/a6cafdb49a7bbf4a88367db209703eee6941e023 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26833 – drm/amd/display: Fix memory leak in dm_sw_fini()
https://notcve.org/view.php?id=CVE-2024-26833
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix memory leak in dm_sw_fini() After destroying dmub_srv, the memory associated with it is not freed, causing a memory leak: unreferenced object 0xffff896302b45800 (size 1024): comm "(udev-worker)", pid 222, jiffies 4294894636 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 6265fd77): [<ffffffff993495ed>] kmalloc_trace+0x29d/0x340 [<ffffffffc0ea4a94>] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [<ffffffffc0ea4e55>] dm_sw_init+0x15/0x2b0 [amdgpu] [<ffffffffc0ba8557>] amdgpu_device_init+0x1417/0x24e0 [amdgpu] [<ffffffffc0bab285>] amdgpu_driver_load_kms+0x15/0x190 [amdgpu] [<ffffffffc0ba09c7>] amdgpu_pci_probe+0x187/0x4e0 [amdgpu] [<ffffffff9968fd1e>] local_pci_probe+0x3e/0x90 [<ffffffff996918a3>] pci_device_probe+0xc3/0x230 [<ffffffff99805872>] really_probe+0xe2/0x480 [<ffffffff99805c98>] __driver_probe_device+0x78/0x160 [<ffffffff99805daf>] driver_probe_device+0x1f/0x90 [<ffffffff9980601e>] __driver_attach+0xce/0x1c0 [<ffffffff99803170>] bus_for_each_dev+0x70/0xc0 [<ffffffff99804822>] bus_add_driver+0x112/0x210 [<ffffffff99807245>] driver_register+0x55/0x100 [<ffffffff990012d1>] do_one_initcall+0x41/0x300 Fix this by freeing dmub_srv after destroying it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: corrige la pérdida de memoria en dm_sw_fini() Después de destruir dmub_srv, la memoria asociada a él no se libera, lo que provoca una pérdida de memoria: objeto sin referencia 0xffff896302b45800 (tamaño 1024) : comm "(udev-worker)", pid 222, sjiffies 4294894636 volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........... ..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ retroceso (crc 6265fd77): [] kmalloc_trace+ 0x29d/0x340 [] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [] dm_sw_init+0x15/0x2b0 [amdgpu] [] 1417/0x24e0 [amdgpu] [] amdgpu_driver_load_kms+0x15 /0x190 [amdgpu] [] amdgpu_pci_probe+0x187/0x4e0 [amdgpu] [] local_pci_probe+0x3e/0x90 [] pci_device_probe+0xc3/0x230 [ ] realmente_probe+0xe2/0x480 [< ffffffff99805c98>] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] v+0x70/0xc0 [] bus_add_driver+0x112/0x210 [< ffffffff99807245>] driver_register+0x55/0x100 [] do_one_initcall+0x41/0x300 Solucione este problema liberando dmub_srv después de destruirlo. • https://git.kernel.org/stable/c/743b9786b14ae0d7d13b3782dccad158e577e9bb https://git.kernel.org/stable/c/b49b022f7dfce85eb77d0d987008fde5c01d7857 https://git.kernel.org/stable/c/33f649f1b1cea39ed360e6c12bba4fac83118e6e https://git.kernel.org/stable/c/58168005337eabef345a872be3f87d0215ff3b30 https://git.kernel.org/stable/c/10c6b90e975358c17856a578419dc449887899c2 https://git.kernel.org/stable/c/541e79265ea7e339a7c4a462feafe9f8f996e04b https://git.kernel.org/stable/c/bae67893578d608e35691dcdfa90c4957debf1d3 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26832 – mm: zswap: fix missing folio cleanup in writeback race path
https://notcve.org/view.php?id=CVE-2024-26832
In the Linux kernel, the following vulnerability has been resolved: mm: zswap: fix missing folio cleanup in writeback race path In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit. However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref'd. Make sure to unlock and put the folio before returning. This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm: zswap: corrige la limpieza de folio faltante en la ruta de carrera de escritura diferida En zswap_writeback_entry(), después de obtener un folio de __read_swap_cache_async(), tomamos el bloqueo del árbol nuevamente para verificar que el intercambio la entrada no fue invalidada y reciclada. Si así fuera, eliminamos la publicación que acabamos de agregar al caché de intercambio y salimos. • https://git.kernel.org/stable/c/2cab13f500a6333bd2b853783ac76be9e4956f8a https://git.kernel.org/stable/c/04fc7816089c5a32c29a04ec94b998e219dfb946 https://git.kernel.org/stable/c/ba700ea13bf0105a4773c654f7d3bef8adb64ab2 https://git.kernel.org/stable/c/14f1992430ef9e647b02aa8ca12c5bcb9a1dffea https://git.kernel.org/stable/c/6156277d1b26cb3fdb6fcbf0686ab78268571644 https://git.kernel.org/stable/c/e2891c763aa2cff74dd6b5e978411ccf0cf94abe https://git.kernel.org/stable/c/e3b63e966cac0bf78aaa1efede1827a252815a1d •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26829 – media: ir_toy: fix a memleak in irtoy_tx
https://notcve.org/view.php?id=CVE-2024-26829
In the Linux kernel, the following vulnerability has been resolved: media: ir_toy: fix a memleak in irtoy_tx When irtoy_command fails, buf should be freed since it is allocated by irtoy_tx, or there is a memleak. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: ir_toy: corrige una fuga de mem en irtoy_tx Cuando falla irtoy_command, se debe liberar buf ya que está asignado por irtoy_tx, o hay una fuga de mem. • https://git.kernel.org/stable/c/4114978dcd24e72415276bba60ff4ff355970bbc https://git.kernel.org/stable/c/a4ac45aff8d38c64104aec21c6529747d94ae75a https://git.kernel.org/stable/c/486a4176bc783df798bce2903824801af8d2c3ae https://git.kernel.org/stable/c/207557e393a135c1b6fe1df7cc0741d2c1789fff https://git.kernel.org/stable/c/be76ad74a43f90f340f9f479e6b04f02125f6aef https://git.kernel.org/stable/c/7219a692ffc00089015ada33b85b334d1a4b6e8e https://git.kernel.org/stable/c/b37259448bbc70af1d0e52a9dd5559a9c29c9621 https://git.kernel.org/stable/c/dc9ceb90c4b42c6e5c6757df1d6257110 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26831 – net/handshake: Fix handshake_req_destroy_test1
https://notcve.org/view.php?id=CVE-2024-26831
In the Linux kernel, the following vulnerability has been resolved: net/handshake: Fix handshake_req_destroy_test1 Recently, handshake_req_destroy_test1 started failing: Expected handshake_req_destroy_test == req, but handshake_req_destroy_test == 0000000000000000 req == 0000000060f99b40 not ok 11 req_destroy works This is because "sock_release(sock)" was replaced with "fput(filp)" to address a memory leak. Note that sock_release() is synchronous but fput() usually delays the final close and clean-up. The delay is not consequential in the other cases that were changed but handshake_req_destroy_test1 is testing that handshake_req_cancel() followed by closing the file actually does call the ->hp_destroy method. Thus the PTR_EQ test at the end has to be sure that the final close is complete before it checks the pointer. We cannot use a completion here because if ->hp_destroy is never called (ie, there is an API bug) then the test will hang. Reported by: Guenter Roeck <linux@roeck-us.net> En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/handshake: Fix handshake_req_destroy_test1 Recientemente, handshake_req_destroy_test1 comenzó a fallar: Se esperaba handshake_req_destroy_test == req, pero handshake_req_destroy_test == 0000000000000000 req == 0000000060f99b40 no ok 11 req_destroy funciona Esto se debe a que "sock_release( calcetín)" fue reemplazado por "fput(filp)" para solucionar una pérdida de memoria. Tenga en cuenta que sock_release() es sincrónico pero fput() normalmente retrasa el cierre y la limpieza finales. El retraso no tiene consecuencias en los otros casos que se cambiaron, pero handshake_req_destroy_test1 está probando que handshake_req_cancel() seguido del cierre del archivo realmente llama al método ->hp_destroy. • https://git.kernel.org/stable/c/4a0f07d71b0483cc08c03cefa7c85749e187c214 https://git.kernel.org/stable/c/1751e44980466e3ebc246d22d3ebd422197704b6 https://git.kernel.org/stable/c/d74226e03df1bf19848f18344401f254345af912 https://git.kernel.org/stable/c/7f97805b8df6e33850e225e6bd3ebd9e246920af https://git.kernel.org/stable/c/4e1d71cabb19ec2586827adfc60d68689c68c194 •