Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: de: módulo: evita la desreferencia del puntero NULL en vsnprintf() En of_modalias(), podemos pasar los parámetros str y len que provocarían un kernel ups en vsnprintf() ya que solo permite pasar un ptr NULL cuando la longitud también es 0. Además, necesitamos filtrar los valores negativos del parámetro len ya que estos darán como resultado un búfer realmente enorme ya que snprintf() toma el parámetro size_t mientras que el nuestro es ssize_t... Encontrado por el Centro de verificación de Linux (linuxtesting.org) con la herramienta de análisis estático Svace.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/kbuf: mantiene la referencia io_buffer_list sobre mmap. Si buscamos el kbuf, nos aseguramos de que no se cancele el registro hasta que hayamos terminado con él. Como estamos dentro de mmap, no podemos usar de forma segura el bloqueo io_uring. Confíe en el hecho de que ahora podemos buscar la lista de búfer en RCU y obtener una referencia a ella, evitando que se cancele el registro hasta que hayamos terminado. La búsqueda devuelve io_buffer_list directamente con su referencia.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Revertir "drm/amd/display: Enviar mensaje de desactivación DTBCLK en la primera confirmación" Esto revierte la confirmación f341055b10bd8be55c3c995dff5f770b236b8ca9. Se observó un bloqueo del sistema; se cree que este compromiso es el punto de regresión.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Revertir "drm/amd/display: Enviar mensaje de desactivación DTBCLK en la primera confirmación" Esto revierte la confirmación f341055b10bd8be55c3c995dff5f770b236b8ca9. Se observó un bloqueo del sistema; se cree que este compromiso es el punto de regresión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: mchp-pci1xxx: corrige una posible desreferencia de puntero null en pci1xxx_spi_probe En la función pci1xxxx_spi_probe, existe un posible puntero null que puede deberse a una asignación de memoria fallida por parte de la función devm_kzalloc. Por lo tanto, es necesario agregar una verificación de puntero null para evitar que se elimine la referencia al puntero null más adelante en el código. Para solucionar este problema, se debe marcar spi_bus->spi_int[iter]. La memoria asignada por devm_kzalloc se liberará automáticamente, por lo que simplemente devuelva -ENOMEM directamente sin preocuparse por pérdidas de memoria.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mlxbf_gige: detiene la interfaz durante el apagado El controlador mlxbf_gige encuentra intermitentemente una excepción de puntero NULL mientras el sistema se apaga mediante el comando "reboot". El mlxbf_driver experimentará una excepción justo después de ejecutar su método de apagado(). Un ejemplo de esta excepción es: No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000070 Información de cancelación de memoria: ESR = 0x0000000096000004 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: error de traducción de nivel 0 Información de cancelación de datos: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 tabla de páginas de usuario: 4k páginas, VA de 48 bits, pgdp=000000011d373000 [0000000000000070] 000000000000, p4d=0000000000000000 Error interno: Ups: 96000004 [#1] CPU SMP: 0 PID: 13 Comm: ksoftirqd/0 Contaminado: GS OE 5.15.0-bf.6.gef6992a #1 Nombre de hardware: https://www.mellanox .com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 21 de abril de 2023 pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] lr: mlxbf_ gige_poll+ 0x54/0x160 [mlxbf_gige] sp: ffff8000080d3c10 x29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58 x26: ffff0000814e7340 x25: a05000 x24: ffffcce72c4ea008 x23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128 x20: 0000000000000000 x19: ffff0000814e4a80 ffffffffffffffff x17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7 x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101 x11: 7f7f7f7f7f7f7f7f x10: ac898b17576267 x9: ffffcce720fa5404 x8: ffff000080812138 x7: 0000000000002e9a x6: 00000000000000080 x5: ffff00008de3b000 x4: 00000000000000000 x3: 0000000000000001 x2: 0000000000000000 x1: 0000000000000000 x0: 00000000000000000 Llamada seguimiento: mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] mlxbf_gige_poll+0x54/0x160 [mlxbf_gige] __napi_poll+0x40/0x1c8 net_rx_action+0x314/0x3a0 __do_softirq+0x128/0x334 _ksoftirqd+0x54/0x6c smpboot_thread_fn+0x14c/0x190 kthread+0x10c/0x110 ret_from_fork+ 0x10/0x20 Código: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002) ---[ seguimiento final 7cc3941aa0d8e6a4 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt Kernel Offset: 0x4ce722520000 de 0xffff 800008000000 PHYS_OFFSET: 0x80000000 Características de la CPU: 0x000005c1,a3330e5a Límite de memoria: ninguno ---[ fin del pánico del kernel - no se sincroniza: Ups: excepción fatal en la interrupción ]--- Durante el apagado del sistema, el apagado() del controlador mlxbf_gige siempre se ejecuta. Sin embargo, el método stop() del controlador solo se ejecutará si la lógica de configuración de la interfaz de red dentro de la distribución de Linux se ha configurado para hacerlo. Si se ejecuta Shutdown() pero stop() no, NAPI permanece habilitada y esto puede provocar una excepción si NAPI se programa mientras la interfaz de hardware solo se ha desinicializado parcialmente. La interfaz de red administrada por el controlador mlxbf_gige debe detenerse correctamente durante el apagado del sistema para que se borre IFF_UP, la interfaz de hardware se ponga en un estado limpio y NAPI se desinicialice por completo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ax25: corrige errores de use after free causados por ax25_ds_del_timer Cuando el dispositivo ax25 se está desconectando, ax25_dev_device_down() llama a ax25_ds_del_timer() para limpiar el Slave_timer. Cuando el controlador del temporizador se está ejecutando, el ax25_ds_del_timer() que llama a del_timer() regresará directamente. Como resultado, podrían ocurrir errores de uso después de la liberación, uno de los escenarios se muestra a continuación: (Subproceso 1) | (Hilo 2) | ax25_ds_timeout() ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //GRATIS | | ax25_dev-> //USE Para mitigar errores, cuando el dispositivo se esté desconectando, use timer_shutdown_sync() para detener el temporizador.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: erspan: asegúrese de que erspan_base_hdr esté presente en skb->head syzbot informó un problema en ip6erspan_rcv() [1] El problema es que ip6erspan_rcv() (y erspan_rcv()) ya no funcionan asegúrese de que erspan_base_hdr esté presente en la parte lineal de skb (skb->head) antes de obtener el campo @ver. Agregue las llamadas pskb_may_pull() que faltan. v2: Vuelva a cargar el puntero iph en erspan_rcv() después de pskb_may_pull() porque skb->head podría haber cambiado. [1] ERROR: KMSAN: valor uninit en pskb_may_pull_reason include/linux/skbuff.h:2742 [en línea] ERROR: KMSAN: valor uninit en pskb_may_pull include/linux/skbuff.h:2756 [en línea] ERROR: KMSAN: uninit -valor en ip6erspan_rcv net/ipv6/ip6_gre.c:541 [en línea] ERROR: KMSAN: valor uninit en gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 pskb_may_pull_reason include/linux/skbuff.h:2742 [en línea ] PSKB_MAY_PULL incluye/linux/skbuff.h: 2756 [en línea] ip6erspan_rcv net/ipv6/ip6_gre.c: 541 [inline] gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c: 610 ip6_protocol_reLiver+0x1d4cu 6/ ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [en línea] NF_HOOK include/linux/netfilter.h:314 [en línea] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:460 [en línea] ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [en línea] ipv6_rcv +0xde/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5538 [en línea] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652 netif_receive_skb_internal net/core/dev.c:5738 [en línea] netif_receive_skb+0x58/0x660 net/core/dev.c:5798 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549 tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [en línea] new_sync_write fs/read_write.c:497 [en línea] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [en línea] __se_sys_write fs/read_write.c:652 [en línea] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entrada_SYSCALL_64 _después_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 [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 tun_alloc_skb drivers/net/tun.c:1525 [en línea] tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [en línea] new_sync_write fs/read_write.c:497 [en línea] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs /read_write.c:655 [en línea] __se_sys_write fs/read_write.c:652 [en línea] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 1 Comunicación 5045: syz-executor114 No contaminado 6.9.0-rc1-syzkaller-00021-g962490525cff #0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: idpf: corrige el pánico del kernel en tipos de paquetes desconocidos. En el caso muy raro de que el controlador desconozca un tipo de paquete, idpf_rx_process_skb_fields regresaría antes de tiempo sin llamar a eth_type_trans para configurar el protocolo skb/el manejador de capa de red. Esto es especialmente problemático si tcpdump se está ejecutando cuando se recibe dicho paquete, es decir, causaría un pánico en el kernel. En su lugar, llame a eth_type_trans para cada paquete, incluso cuando se desconozca el tipo de paquete.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ipv6: Se corrigió la recursividad infinita en fib6_dump_done(). syzkaller informó infinitas llamadas recursivas de fib6_dump_done() durante la destrucción del socket netlink. [1] Desde el registro, syzkaller envió un mensaje AF_UNSPEC RTM_GETROUTE y luego se generó la respuesta. El siguiente recvmmsg() reanudó el volcado para IPv6, pero la primera llamada de inet6_dump_fib() falló en kzalloc() debido a la inyección de falla. [0] 12:01:34 ejecutando el programa 3: r0 = socket$nl_route(0x10, 0x3, 0x0) sendmsg$nl_route(r0, ... recorte ...) recvmmsg(r0, ... recorte ...) (fail_nth: 8) Aquí, fib6_dump_done() se configuró en nlk_sk(sk)->cb.done, y la siguiente llamada de inet6_dump_fib() se configuró en nlk_sk(sk)->cb.args[3]. syzkaller dejó de recibir la respuesta a la mitad y finalmente netlink_sock_destruct() llamó a nlk_sk(sk)->cb.done(). fib6_dump_done() llama a fib6_dump_end() y nlk_sk(sk)->cb.done() si todavía no es NULL. fib6_dump_end() reescribe nlk_sk(sk)->cb.done() por nlk_sk(sk)->cb.args[3], pero tiene la misma función, no NULL, llamándose a sí mismo de forma recursiva y accediendo a la página de protección de pila. Para evitar el problema, configuremos el destructor después de kzalloc(). [0]: FAULT_INJECTION: forzando un fallo. nombre failslab, intervalo 1, probabilidad 0, espacio 0, tiempos 0 CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Nombre del hardware: PC estándar QEMU (i440FX + PIIX , 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 01/04/2014 Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:117) debería_fail_ex (lib/fault-inject.c :52 lib/fault-inject.c:153) must_failslab (mm/slub.c:3733) kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992) inet6_dump_fib (./ include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662) rtnl_dump_all (net/core/rtnetlink.c:4029) netlink_dump (net/netlink/af_netlink. c:2269) netlink_recvmsg (net/netlink/af_netlink.c:1988) ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801) ___sys_recvmsg (net/socket.c:2846) do_recvmmsg (net/socket.c :2943) __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034) [1]: ERROR: La página de protección de la pila de TAREA fue visitada en 00000000f2fa9af1 (la pila es 00000000b7912430..000000009a436be b) pila página de protección: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996) , BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 01/04/2014 Cola de trabajo: eventos netlink_sock_destruct_work RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570) Código: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d980000 EFLAGS: 00010293 RAX: 00000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3 RDX: 881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358 RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000000000000 0R11: 0000000000000224 R12: 0000000000000000 R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68 FS: 0000000000000000(0000) ffff88811b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d97fff8 CR3: 0000000102309002 000000000770ef0 PKRU : 55555554 Seguimiento de llamadas: <#DF> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminador 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminador 1)). .. fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminador 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminador 1)) netlink_sock_destruct (net/netlink/af_netlink.c:401) __sk_destruct (net/ core/sock.c:2177 (discriminador 2)) sk_destruct (net/core/sock.c:2224) __sk_free (net/core/sock.c:2235) sk_free (net/core/sock.c:2246) Process_one_work ( kernel/workqueue.c:3259)-truncado-

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: no acepte skbs GSO que no sean de túnel que aterricen en un túnel Cuando rx-udp-gro-forwarding está habilitado, los paquetes UDP pueden recibir GRO al reenviarse. Si dichos paquetes pudieran aterrizar en un túnel, esto puede causar varios problemas y udp_gro_receive se asegura de que este no sea el caso buscando un socket coincidente. Esto se realiza en udp4/6_gro_lookup_skb pero sólo en las redes actuales. Este es un problema con los paquetes tunelizados cuando el punto final está en otra red. En tales casos, los paquetes se almacenarán en el nivel UDP, lo que generará varios problemas más adelante. Lo mismo puede pasar con rx-gro-list. Vimos esto con paquetes geneve siendo GRO en el nivel UDP. En tal caso, se establece gso_size; luego, el paquete pasa por la ruta geneve rx, se extrae el encabezado geneve, se ajusta el desplazamiento y los skbs frag_list no se ajustan con respecto a geneve. Cuando esos skbs lleguen a skb_fragment, se comportará mal. Son posibles diferentes resultados dependiendo del aspecto de los skbs GROed; desde paquetes corruptos hasta fallas del kernel. Un ejemplo es un BUG_ON[1] activado en skb_segment mientras se procesa frag_list. Debido a que gso_size es incorrecto (se extrajo el encabezado geneve), skb_segment cree que hay un "tamaño de encabezado geneve" de datos en frag_list, aunque en realidad es el siguiente paquete. El BUG_ON en sí no tiene nada que ver con el problema. Éste es sólo uno de los posibles problemas. Buscar un socket coincidente en udp_gro_receive es frágil: la búsqueda podría extenderse a todas las redes (sin hablar de rendimiento), pero nada impide que esos paquetes se modifiquen en el medio y todavía no pudimos encontrar un socket coincidente. Está bien mantener la lógica actual allí, ya que debería cubrir la mayoría de los casos, pero también debemos asegurarnos de manejar los paquetes de túnel que se procesan en GRO demasiado pronto. Esto se hace ampliando las comprobaciones en udp_unexpected_gso: los paquetes OSG que carecen de los bits SKB_GSO_UDP_TUNNEL/_CSUM y que aterrizan en un túnel deben segmentarse. [1] ¡BUG del kernel en net/core/skbuff.c:4408! RIP: 0010:skb_segment+0xd2a/0xf70 __udp_gso_segment+0xaa/0x560

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: of:dynamic: Sincronizar of_changeset_destroy() con las eliminaciones de devlink En la siguiente secuencia: 1) of_platform_depopulate() 2) of_overlay_remove() Durante el paso 1, los dispositivos se destruyen y los devlinks son remoto. Durante el paso 2, los nodos OF se destruyen, pero __of_changeset_entry_destroy() puede generar advertencias relacionadas con la falta de of_node_put(): ERROR: pérdida de memoria, recuento esperado 1 en lugar de 2... De hecho, durante las eliminaciones de devlink realizadas en el paso 1, la eliminación La liberación del dispositivo (y el of_node adjunto) se realiza mediante un trabajo en cola en una cola de trabajo y, por lo tanto, se realiza de forma asincrónica con respecto a las llamadas a funciones. Cuando la advertencia está presente, se llamará a of_node_put() pero erróneamente demasiado tarde desde el trabajo de la cola de trabajo. Para asegurarse de que cualquier eliminación de devlink en curso se realice antes de la destrucción de of_node, sincronice of_changeset_destroy() con las eliminaciones de devlink.