CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35984 – i2c: smbus: fix NULL function pointer dereference
https://notcve.org/view.php?id=CVE-2024-35984
In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: fix NULL function pointer dereference Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer. [wsa: dropped the simplification in core-smbus to avoid theoretical regressions] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: smbus: corrige la desreferencia del puntero de función NULL. Baruch informó de un OOPS al usar el controlador de designware como destino únicamente. Los modos de solo objetivo rompen el supuesto de que siempre hay una función de transferencia disponible. • https://git.kernel.org/stable/c/63453b59e41173241c4efe9335815f6432fa8586 https://git.kernel.org/stable/c/40f1d79f07b49c8a64a861706e5163f2db4bd95d https://git.kernel.org/stable/c/ad3c3ac7a03be3697114f781193dd3e9d97e6e23 https://git.kernel.org/stable/c/5fd72404587d7db4acb2d241fd8c387afb0a7aec https://git.kernel.org/stable/c/5a09eae9a7db597fe0c1fc91636205b4a25d2620 https://git.kernel.org/stable/c/4e75e222d397c6752b229ed72fc4644c8c36ecde https://git.kernel.org/stable/c/e3425674ff68dc521c57c6eabad0cbd20a027d85 https://git.kernel.org/stable/c/357c64ef1ef39b1e7cd91ab6bdd304d04 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35982 – batman-adv: Avoid infinite loop trying to resize local TT
https://notcve.org/view.php?id=CVE-2024-35982
In the Linux kernel, the following vulnerability has been resolved: batman-adv: Avoid infinite loop trying to resize local TT If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet. But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110) in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more. There are other scenarios possible with a similar result. The number of BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. • https://git.kernel.org/stable/c/a19d3d85e1b854e4a483a55d740a42458085560d https://git.kernel.org/stable/c/5eaeaa72113865661568002bb57d611492451d3e https://git.kernel.org/stable/c/04720ea2e6c64459a90ca28570ea78335eccd924 https://git.kernel.org/stable/c/b3ddf6904073990492454b1dd1c10a24be8c74c6 https://git.kernel.org/stable/c/70a8be9dc2fb65d67f8c1e0c88c587e08e2e575d https://git.kernel.org/stable/c/87b6af1a7683e021710c08fc0551fc078346032f https://git.kernel.org/stable/c/3fe79b2c83461edbbf86ed8a6f3924820ff89259 https://git.kernel.org/stable/c/4ca2a5fb54ea2cc43edea614207fcede5 • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35978 – Bluetooth: Fix memory leak in hci_req_sync_complete()
https://notcve.org/view.php?id=CVE-2024-35978
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix memory leak in hci_req_sync_complete() In 'hci_req_sync_complete()', always free the previous sync request state before assigning reference to a new one. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: corrija la pérdida de memoria en hci_req_sync_complete() En 'hci_req_sync_complete()', libere siempre el estado de solicitud de sincronización anterior antes de asignar una referencia a una nueva. • https://git.kernel.org/stable/c/f60cb30579d3401cab1ed36b42df5c0568ae0ba7 https://git.kernel.org/stable/c/89a32741f4217856066c198a4a7267bcdd1edd67 https://git.kernel.org/stable/c/4beab84fbb50df3be1d8f8a976e6fe882ca65cb2 https://git.kernel.org/stable/c/8478394f76c748862ef179a16f651f752bdafaf0 https://git.kernel.org/stable/c/75193678cce993aa959e7764b6df2f599886dd06 https://git.kernel.org/stable/c/66fab1e120b39f8f47a94186ddee36006fc02ca8 https://git.kernel.org/stable/c/9ab5e44b9bac946bd49fd63264a08cd1ea494e76 https://git.kernel.org/stable/c/e4cb8382fff6706436b66eafd9c0ee857 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: 6.7EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35976 – xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING
https://notcve.org/view.php?id=CVE-2024-35976
In the Linux kernel, the following vulnerability has been resolved: xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING syzbot reported an illegal copy in xsk_setsockopt() [1] Make sure to validate setsockopt() @optlen parameter. [1] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549 CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fb40587de69 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69 RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006 RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08 </TASK> Allocated by task 7549: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3966 [inline] __kmalloc+0x233/0x4a0 mm/slub.c:3979 kmalloc include/linux/slab.h:632 [inline] __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 The buggy address belongs to the object at ffff888028c6cde0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 1 bytes to the right of allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2) The buggy address belongs to the physical page: page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff) page_type: 0xffffffff() raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001 raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533 prep_new_page mm/page_alloc.c: ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: xsk: validar la entrada del usuario para XDP_{UMEM|COMPLETION}_FILL_RING syzbot informó una copia ilegal en xsk_setsockopt() [1] Asegúrese de validar el parámetro @optlen setsockopt(). [1] BUG: KASAN: losa fuera de límites en copy_from_sockptr_offset include/linux/sockptr.h:49 [en línea] ERROR: KASAN: losa fuera de límites en copy_from_sockptr include/linux/sockptr.h:55 [en línea] ERROR: KASAN: losa fuera de límites en xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 Lectura de tamaño 4 en la dirección ffff888028c6cde3 mediante la tarea syz-executor.0/7549 CPU: 0 PID: 7549 Comm: syz-executor.0 No contaminado 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack .c:88 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [en línea] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/ 0x180 mm/kasan/report.c:601 copy_from_sockptr_offset include/linux/sockptr.h:49 [en línea] copy_from_sockptr include/linux/sockptr.h:55 [en línea] xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [en línea] __se_sys_setsockopt net/socket.c:2340 [en línea] x64_sys_setsockopt+0xb5/ 0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fb40587de69 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 0c8 EFLAGS: 00000246 ORIG_RAX : 0000000000000036 RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69 RDX: 0000000000000005 RSI: 000000000000011b RDI: 000000000 0000006 RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020001980 R11: 0000000000000246 R12: 000000000 0000000 R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08 Asignado por tarea 7549: kasan_save_stack mm/kasan/common.c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 veneno_kmalloc_redzone mm/kasan/common.c:370 [en línea] __kasan_kmalloc+0x98/ 0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [en línea] __do_kmalloc_node mm/slub.c:3966 [en línea] __kmalloc+0x233/0x4a0 mm/slub.c:3979 kmalloc include/linux /slab.h:632 [en línea] __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 334 __do_sys_setsockopt net/ socket.c:2343 [en línea] __se_sys_setsockopt net/socket.c:2340 [en línea] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 El error la dirección pertenece al objeto en ffff888028c6cde0 que pertenece al caché kmalloc-8 de tamaño 8 La dirección con errores se encuentra 1 byte a la derecha de la región asignada de 2 bytes [ffff888028c6cde0, ffff888028c6cde2) La dirección con errores pertenece a la página física: página:ffffea0000a31b00 refcount:1 mapcount:0 Mapeo: 00000000000000000000 ÍNDICE: 0xffff888028c6c9c0 pfn: 0x28c6c Anon Flags: 0xffff00000000800 (Slab | Node = 0 | Zone = 1 | LastCpupid = 0x7ff) Page_Type: 0xffffffffffff () RAW: 00FFF000000800 0000000000000000 Dead000000000001 Raw: FFFFF888028C6C9C0 000000000080800057 00000001FFFFFFFFFFFFFFF 0000000000000000 Página arrojada porque: Kasan : mal acceso detectado page_owner rastrea la página como página asignada por última vez mediante orden 0, migrar tipo Inamovible, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223 set _page_owner incluye /linux/page_owner.h:31 [en línea] post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533 prep_new_page mm/page_alloc.c: ---truncado--- • https://git.kernel.org/stable/c/423f38329d267969130fb6f2c685f73d72687558 https://git.kernel.org/stable/c/beb99266830520e15fbc6ca8cc5a5240d76851fd https://git.kernel.org/stable/c/0b45c25d60e38f5c2cb6823f886773a34323306d https://git.kernel.org/stable/c/a82984b3c6a7e8c7937dba6e857ddf829d149417 https://git.kernel.org/stable/c/f0a068de65d5b7358e9aff792716afa9333f3922 https://git.kernel.org/stable/c/2a523f14a3f53b46ff0e1fafd215b0bc5f6783aa https://git.kernel.org/stable/c/b143e19dc28c3211f050f7848d87d9b0a170e10c https://git.kernel.org/stable/c/2eb979fbb2479bcd7e049f2f9978b6590 • CWE-787: Out-of-bounds Write •
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. Si se encuentra algo más que ETH_P_IPV6 o ETH_P_IP en skb->protocol, pskb_inet_may_pull() no hace nada en absoluto. Si la persona que llama proporcionó una etiqueta vlan (af_packet en el caso de syzbot), es posible que el encabezado de la red no apunte a la ubicación correcta y que la parte lineal de skb sea más pequeña de lo esperado. Agregue skb_vlan_inet_prepare() para realizar una validación completa de Mac. Utilice esto en Ginebra por el momento. • 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 •