Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tick/nohz: unexport __init-annotated tick_nohz_full_setup() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it had been broken for a decade. Commit 28438794aba4 ("modpost: fix section mismatch check for exported init/exit sections") fixed it so modpost started to warn it again, then this showed up: MODPOST vmlinux.symvers WARNING: modpost: vmlinux.o(___ksymtab_gpl+tick_nohz_full_setup+0x0): Section mismatch in reference from the variable __ksymtab_tick_nohz_full_setup to the function .init.text:tick_nohz_full_setup() The symbol tick_nohz_full_setup is exported and annotated __init Fix this by removing the __init annotation of tick_nohz_full_setup or drop the export. Drop the export because tick_nohz_full_setup() is only called from the built-in code in kernel/sched/isolation.c.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memoria: samsung: exynos5422-dmc: Se corrige la fuga de refcount en of_get_dram_timings of_parse_phandle() devuelve un puntero de nodo con refcount incrementado, deberíamos usar of_node_put() en él cuando ya no sea necesario. Esta función no llama a of_node_put() en algunas rutas de error. Para unificar la estructura, agregue la etiqueta put_node y vaya a ella en caso de errores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: cns3xxx: Se ha corregido la pérdida de recuento de referencias en cns3xxx_init. of_find_compatible_node() devuelve un puntero de nodo con el recuento de referencias incrementado. Deberíamos usar of_node_put() en él cuando haya terminado. Se ha añadido el error of_node_put() que falta para evitar la pérdida de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: bcm: brcmstb: pm: pm-arm: Se corrige la pérdida de refcount en brcmstb_pm_probe of_find_matching_node() devuelve un puntero de nodo con refcount incrementado, deberíamos usar of_node_put() en él cuando ya no lo necesitemos. Agrega of_node_put() faltante para evitar la pérdida de refcount. En brcmstb_init_sram, pasa dn a of_address_to_resource(), of_address_to_resource() llamará a of_find_device_by_node() para tomar la referencia, por lo que deberíamos liberar la referencia devuelta por of_find_matching_node().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: Se corrige la pérdida de recuento de referencias en axxia_boot_secondary. of_find_compatible_node() devuelve un puntero de nodo con el recuento de referencias incrementado; cuando termine, debemos usar of_node_put() en él. Agregue el error of_node_put() faltante para evitar la pérdida de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: exynos: Se corrige la fuga de refcount en exynos_map_pmu of_find_matching_node() devuelve un puntero de nodo con refcount incrementado, deberíamos usar of_node_put() en él cuando ya no lo necesitemos. Agregue of_node_put() faltante para evitar la fuga de refcount. of_node_put() verifica el puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xtensa: xtfpga: Se corrige el error de pérdida de recuento de referencias en la configuración. En machine_setup(), of_find_compatible_node() devolverá un puntero de nodo con el recuento de referencias incrementado. Deberíamos usar of_node_put() cuando ya no se use.

Razón rechazado: esta identificación de CVE ha sido rechazada o retirada por su autoridad de numeración de CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: gs_usb: gs_usb_open/close(): corrige pérdida de memoria El controlador gs_usb parece sufrir un problema común a muchos controladores de adaptadores USB CAN, ya que realiza usb_alloc_coherent() para asignar una cantidad de bloques de solicitud USB (URB) para RX y luego se basa en usb_kill_anchored_urbs() para liberarlos, pero esto en realidad no los libera. Como resultado, esto puede estar perdiendo memoria DMA que ha sido utilizada por el controlador. Esta confirmación es una adaptación de las técnicas encontradas en el controlador esd_usb2 donde un patrón de diseño similar condujo a una pérdida de memoria. Libera explícitamente los URB RX y su memoria DMA a través de una llamada a usb_free_coherent(). Dado que los URB RX se asignaron en gs_can_open(), los eliminamos en gs_can_close() en lugar de en la función de desconexión como se hizo en esd_usb2. Para obtener más información, consulte 928150fad41b ("can: esd_usb2: reparar pérdida de memoria").

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: fix lockdep splat in in6_dump_addrs() As reported by syzbot, we should not use rcu_dereference() when rcu_read_lock() is not held. WARNING: suspicious RCU usage 5.19.0-rc2-syzkaller #0 Not tainted net/ipv6/addrconf.c:5175 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by syz-executor326/3617: #0: ffffffff8d5848e8 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xae/0xc20 net/netlink/af_netlink.c:2223 stack backtrace: CPU: 0 PID: 3617 Comm: syz-executor326 Not tainted 5.19.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 in6_dump_addrs+0x12d1/0x1790 net/ipv6/addrconf.c:5175 inet6_dump_addr+0x9c1/0xb50 net/ipv6/addrconf.c:5300 netlink_dump+0x541/0xc20 net/netlink/af_netlink.c:2275 __netlink_dump_start+0x647/0x900 net/netlink/af_netlink.c:2380 netlink_dump_start include/linux/netlink.h:245 [inline] rtnetlink_rcv_msg+0x73e/0xc90 net/core/rtnetlink.c:6046 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 ____sys_sendmsg+0x6eb/0x810 net/socket.c:2492 ___sys_sendmsg+0xf3/0x170 net/socket.c:2546 __sys_sendmsg net/socket.c:2575 [inline] __do_sys_sendmsg net/socket.c:2584 [inline] __se_sys_sendmsg net/socket.c:2582 [inline] __x64_sys_sendmsg+0x132/0x220 net/socket.c:2582 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: túneles: no suponga que el encabezado mac está configurado en skb_tunnel_check_pmtu() La depuración agregada recientemente en el commit f9aefd6b2aa3 ("net: advertir si el encabezado mac no estaba configurado") detectó un error en skb_tunnel_check_pmtu(), como se muestra en este informe de syzbot [1]. En las rutas ndo_start_xmit(), realmente no hay necesidad de usar skb->mac_header, porque se supone que skb->data debe apuntar a él. [1] WARNING: CPU: 1 PID: 8604 at include/linux/skbuff.h:2784 skb_mac_header_len include/linux/skbuff.h:2784 [inline] WARNING: CPU: 1 PID: 8604 at include/linux/skbuff.h:2784 skb_tunnel_check_pmtu+0x5de/0x2f90 net/ipv4/ip_tunnel_core.c:413 Modules linked in: CPU: 1 PID: 8604 Comm: syz-executor.3 Not tainted 5.19.0-rc2-syzkaller-00443-g8720bd951b8e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:skb_mac_header_len include/linux/skbuff.h:2784 [inline] RIP: 0010:skb_tunnel_check_pmtu+0x5de/0x2f90 net/ipv4/ip_tunnel_core.c:413 Code: 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 80 3c 02 00 0f 84 b9 fe ff ff 4c 89 ff e8 7c 0f d7 f9 e9 ac fe ff ff e8 c2 13 8a f9 <0f> 0b e9 28 fc ff ff e8 b6 13 8a f9 48 8b 54 24 70 48 b8 00 00 00 RSP: 0018:ffffc90002e4f520 EFLAGS: 00010212 RAX: 0000000000000324 RBX: ffff88804d5fd500 RCX: ffffc90005b52000 RDX: 0000000000040000 RSI: ffffffff87f05e3e RDI: 0000000000000003 RBP: ffffc90002e4f650 R08: 0000000000000003 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000000 R12: 000000000000ffff R13: 0000000000000000 R14: 000000000000ffcd R15: 000000000000001f FS: 00007f3babba9700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000075319000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: geneve_xmit_skb drivers/net/geneve.c:927 [inline] geneve_xmit+0xcf8/0x35d0 drivers/net/geneve.c:1107 __netdev_start_xmit include/linux/netdevice.h:4805 [inline] netdev_start_xmit include/linux/netdevice.h:4819 [inline] __dev_direct_xmit+0x500/0x730 net/core/dev.c:4309 dev_direct_xmit include/linux/netdevice.h:3007 [inline] packet_direct_xmit+0x1b8/0x2c0 net/packet/af_packet.c:282 packet_snd net/packet/af_packet.c:3073 [inline] packet_sendmsg+0x21f4/0x55d0 net/packet/af_packet.c:3104 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 ____sys_sendmsg+0x6eb/0x810 net/socket.c:2489 ___sys_sendmsg+0xf3/0x170 net/socket.c:2543 __sys_sendmsg net/socket.c:2572 [inline] __do_sys_sendmsg net/socket.c:2581 [inline] __se_sys_sendmsg net/socket.c:2579 [inline] __x64_sys_sendmsg+0x132/0x220 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f3baaa89109 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3babba9168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f3baab9bf60 RCX: 00007f3baaa89109 RDX: 0000000000000000 RSI: 0000000020000a00 RDI: 0000000000000003 RBP: 00007f3baaae305d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe74f2543f R14: 00007f3babba9300 R15: 0000000000022000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: mover la creación del enlace bc de nuevo a tipc_node_create Shuang Li reported a NULL pointer dereference crash: [] BUG: kernel NULL pointer dereference, address: 0000000000000068 [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc] [] Call Trace: [] [] tipc_bcast_rcv+0xa2/0x190 [tipc] [] tipc_node_bc_rcv+0x8b/0x200 [tipc] [] tipc_rcv+0x3af/0x5b0 [tipc] [] tipc_udp_recv+0xc7/0x1e0 [tipc] It was caused by the 'l' passed into tipc_bcast_rcv() is NULL. Cuando crea un nodo en tipc_node_check_dest(), después de insertar el nuevo nodo en la tabla hash en tipc_node_create(), crea el enlace bc. Sin embargo, hay una brecha entre esta inserción y la creación del enlace bc, un paquete bc puede llegar y obtener el nodo de la tabla hash y luego intentar desreferenciar su enlace bc, que es NULL. Este parche es para solucionarlo moviendo la creación del enlace bc antes de insertarlo en la tabla hash. Tenga en cuenta que para que un nodo preliminar se vuelva "real", la creación del enlace bc también debe llamarse antes de que se vuelva a crear, ya que no lo creamos para los nodos preliminares.