CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35974 – block: fix q->blkg_list corruption during disk rebind
https://notcve.org/view.php?id=CVE-2024-35974
In the Linux kernel, the following vulnerability has been resolved: block: fix q->blkg_list corruption during disk rebind Multiple gendisk instances can allocated/added for single request queue in case of disk rebind. blkg may still stay in q->blkg_list when calling blkcg_init_disk() for rebind, then q->blkg_list becomes corrupted. Fix the list corruption issue by: - add blkg_init_queue() to initialize q->blkg_list & q->blkcg_mutex only - move calling blkg_init_queue() into blk_alloc_queue() The list corruption should be started since commit f1c006f1c685 ("blk-cgroup: synchronize pd_free_fn() from blkg_free_workfn() and blkcg_deactivate_policy()") which delays removing blkg from q->blkg_list into blkg_free_workfn(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloque: corrige la corrupción de q->blkg_list durante la revinculación del disco. • https://git.kernel.org/stable/c/1059699f87eb0b3aa9d574b91a572d534897134a https://git.kernel.org/stable/c/740ffad95ca8033bd6e080ed337655b13b4d38ac https://git.kernel.org/stable/c/858c489d81d659af17a4d11cfaad2afb42e47a76 https://git.kernel.org/stable/c/8b8ace080319a866f5dfe9da8e665ae51d971c54 •
CVSS: 5.5EPSS: 0%CPEs: 10EXPL: 0CVE-2024-35973 – geneve: fix header validation in geneve[6]_xmit_skb
https://notcve.org/view.php?id=CVE-2024-35973
In the Linux kernel, the following vulnerability has been resolved: geneve: fix header validation in geneve[6]_xmit_skb syzbot is able to trigger an uninit-value in geneve_xmit() [1] Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield()) uses skb_protocol(skb, true), pskb_inet_may_pull() is only using skb->protocol. If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb->protocol, pskb_inet_may_pull() does nothing at all. If a vlan tag was provided by the caller (af_packet in the syzbot case), the network header might not point to the correct location, and skb linear part could be smaller than expected. Add skb_vlan_inet_prepare() to perform a complete mac validation. Use this in geneve for the moment, I suspect we need to adopt this more broadly. v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest - Only call __vlan_get_protocol() for vlan types. v2,v3 - Addressed Sabrina comments on v1 and v2 [1] BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline] BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 geneve_xmit_skb drivers/net/geneve.c:910 [inline] geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: geneve: corrige la validación del encabezado en geneve[6]_xmit_skb syzbot puede activar un valor uninit en geneve_xmit() [1] Problema: mientras que la mayoría de los asistentes de túnel IP (como ip_tunnel_get_dsfield( )) usa skb_protocol(skb, true), pskb_inet_may_pull() solo usa skb->protocol. ... Sospecho que debemos adoptarlo de manera más amplia. v4: Jakub informó que v3 rompió la autoprueba de l2_tos_ttl_inherit.sh: solo llame a __vlan_get_protocol() para tipos de VLAN. v2,v3: se abordaron los comentarios de Sabrina sobre v1 y v2 [1] ERROR: KMSAN: valor uninit en geneve_xmit_skb drivers/net/geneve.c:910 [en línea] ERROR: KMSAN: valor uninit en geneve_xmit+0x302d/0x5420 drivers/ net/geneve.c:1030 geneve_xmit_skb drivers/net/geneve.c:910 [en línea] geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 __netdev_start_xmit include/linux/netdevice.h:4903 [en línea] netdev_start_xmit include/ linux/netdevice.h:4917 [en línea] xmit_one net/core/dev.c:3531 [en línea] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c: 4335 dev_queue_xmit include/linux/netdevice.h:3091 [en línea] paquete_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 paquete_snd net/packet/af_packet.c:3081 [en línea] packet_sendmsg+0x8bb0/0x9ef0 net/packet/ af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [en línea ] __se_sys_sendto net/socket.c:2199 [en línea] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit se creó en slab_post_alloc _hook mm/slub.c:3804 [en línea] slab_alloc_node mm/slub.c:3845 [en línea] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c: 668 alloc_skb include/linux/skbuff.h:1318 [en línea] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 paquete_alloc_skb net/packet/af_packet.c :2930 [en línea] paquete_snd net/packet/af_packet.c:3024 [en línea] paquete_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x30f/0x380 net/ Socket.c: 745 __sys_sendto+0x685/0x830 net/Socket.c: 2191 __do_sys_sendto net/Socket.c: 2203 [en línea] __se_sys_sendto net/Socket.c: 2199 [Inline] __X64_SYS_SENDTO+0x125/0x1d0 net/Socket/Socket. 2199 do_syscall_64+0xd5/0x1f0 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 0 PID: 5033 Comm: syz-executor346 No contaminado 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0 Nombre de hardware: Google Google Compute Engine/Google Motor de cómputo, BIOS Google 29/02/2024 • https://git.kernel.org/stable/c/35385daa8db320d2d9664930c28e732578b0d7de https://git.kernel.org/stable/c/6f92124d74419797fadfbcd5b7a72c384a6413ad https://git.kernel.org/stable/c/71ad9260c001b217d704cda88ecea251b2d367da https://git.kernel.org/stable/c/d13f048dd40e8577260cd43faea8ec9b77520197 https://git.kernel.org/stable/c/9a51e36ebf433adf59c051bec33f5aa54640bb4d https://git.kernel.org/stable/c/21815f28af8081b258552c111774ff320cf38d38 https://git.kernel.org/stable/c/43be590456e1f3566054ce78ae2dbb68cbe1a536 https://git.kernel.org/stable/c/d3adf11d7993518a39bd02b383cfe657c •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35972 – bnxt_en: Fix possible memory leak in bnxt_rdma_aux_device_init()
https://notcve.org/view.php?id=CVE-2024-35972
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix possible memory leak in bnxt_rdma_aux_device_init() If ulp = kzalloc() fails, the allocated edev will leak because it is not properly assigned and the cleanup path will not be able to free it. Fix it by assigning it properly immediately after allocation. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bnxt_en: corrige una posible pérdida de memoria en bnxt_rdma_aux_device_init() Si ulp = kzalloc() falla, el edev asignado se perderá porque no está asignado correctamente y la ruta de limpieza no podrá liberarlo. • https://git.kernel.org/stable/c/30343221132430c24b468493c861f71e2bad131f https://git.kernel.org/stable/c/c60ed825530b8c0cc2b524efd39b1d696ec54004 https://git.kernel.org/stable/c/10a9d6a7513f93d7faffcb341af0aa42be8218fe https://git.kernel.org/stable/c/7ac10c7d728d75bc9daaa8fade3c7a3273b9a9ff • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35971 – net: ks8851: Handle softirqs at the end of IRQ thread to fix hang
https://notcve.org/view.php?id=CVE-2024-35971
In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Handle softirqs at the end of IRQ thread to fix hang The ks8851_irq() thread may call ks8851_rx_pkts() in case there are any packets in the MAC FIFO, which calls netif_rx(). ... En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ks8851: maneja softirqs al final del subproceso IRQ para corregir el bloqueo. • https://git.kernel.org/stable/c/797047f875b5463719cc70ba213eb691d453c946 https://git.kernel.org/stable/c/492337a4fbd1421b42df684ee9b34be2a2722540 https://git.kernel.org/stable/c/cba376eb036c2c20077b41d47b317d8218fe754f https://git.kernel.org/stable/c/49d5d70538b6b8f2a3f8f1ac30c1f921d4a0929b https://git.kernel.org/stable/c/be0384bf599cf1eb8d337517feeb732d71f75a6f http://www.openwall.com/lists/oss-security/2024/05/30/1 http://www.openwall.com/lists/oss-security/2024/05/30/2 •
CVSS: 6.3EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35970 – af_unix: Clear stale u->oob_skb.
https://notcve.org/view.php?id=CVE-2024-35970
In the Linux kernel, the following vulnerability has been resolved: af_unix: Clear stale u->oob_skb. syzkaller started to report deadlock of unix_gc_lock after commit 4090fa373f0e ("af_unix: Replace garbage collection algorithm."), but it just uncovers the bug that has been there since commit 314001f0bf92 ("af_unix: Add OOB support"). The repro basically does the following. from socket import * from array import array c1, c2 = socketpair(AF_UNIX, SOCK_STREAM) c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array("i", [c2.fileno()]))], MSG_OOB) c2.recv(1) # blocked as no normal data in recv queue c2.close() # done async and unblock recv() c1.close() # done async and trigger GC A socket sends its file descriptor to itself as OOB data and tries to receive normal data, but finally recv() fails due to async close(). The problem here is wrong handling of OOB skb in manage_oob(). ... En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: Borrar u->oob_skb obsoleto. syzkaller comenzó a informar un punto muerto de unix_gc_lock después de la confirmación 4090fa373f0e ("af_unix: Reemplazar el algoritmo de recolección de basura"), pero simplemente descubre el error que ha estado ahí desde la confirmación 314001f0bf92 ("af_unix: Agregar soporte OOB"). • https://git.kernel.org/stable/c/314001f0bf927015e459c9d387d62a231fe93af3 https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153 https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9 https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6 https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e •