Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ila: llamar a nf_unregister_net_hooks() antes de que syzbot encuentre una lectura de uso posterior a la liberación en ila_nf_input [1] El problema aquí es que ila_xlat_exit_net() libera la tabla rhash y luego llama a nf_unregister_net_hooks(). Debería hacerse de forma inversa, con unsynchronous_rcu(). Esta es una buena combinación para un método pre_exit(). [1] ERROR: KASAN: use after free en rht_key_hashfn include/linux/rhashtable.h:159 [en línea] ERROR: KASAN: use after free en __rhashtable_lookup include/linux/rhashtable.h:604 [en línea] ERROR: KASAN: use after free en rhashtable_lookup include/linux/rhashtable.h:646 [en línea] ERROR: KASAN: use after free en rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 Lectura de tamaño 4 en la dirección ffff888064620008 por la tarea ksoftirqd/0/16 CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 No contaminado 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:93 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 rht_key_hashfn include/linux/rhashtable.h:159 [en línea] __rhashtable_lookup include/linux/rhashtable.h:604 [en línea] rhashtable_lookup include/linux/rhashtable.h:646 [en línea] rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [en línea] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [en línea] ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190 nf_hook_entry_hookfn include/linux/netfilter.h:154 [en línea] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [en línea] NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312 __netif_receive_skb_one_core net/core/dev.c:5661 [en línea] __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6108 __napi_poll+0xcb/0x490 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [en línea] net_rx_action+0x89b/0x1240 net/core/dev.c:6963 handle_softirqs+0x2c4/0x970 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:928 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 La dirección con errores pertenece a la página física: page: refcount:0 mapcount:0 mapping:0000000000000000 índice:0x0 pfn:0x64620 indicadores: 0xfff00000000000(nodo=0|zona=1|lastcpupid=0x7ff) tipo_página: 0xbfffffff(amigo) sin procesar: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000 sin procesar: 000000000000000 000000000000003 00000000bfffffff 0000000000000000 página volcada porque: kasan: se detectó un acceso incorrecto page_owner rastrea la página como liberada última página asignada mediante orden 3, migrantstype inamovible, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (ejecutor del sistema), ts 73611328570, free_ts 618981657187 establecer_propietario_de_página include/linux/page_owner.h:32 [en línea] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493 preparar_nueva_página mm/page_alloc.c:1501 [en línea] obtener_página_de_lista_libre+0x2e4c/0x2f10 mm/page_alloc.c:3439 __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695 __alloc_pages_node_noprof include/linux/gfp.h:269 [en línea] alloc_pages_node_noprof include/linux/gfp.h:296 [en línea] ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103 __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130 __do_kmalloc_node mm/slub.c:4146 [en línea] __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164 __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650 bucket_table_alloc lib/rhashtable.c:186 [en línea] ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp_bpf: se corrige el valor de retorno de tcp_bpf_sendmsg() Cuando copiamos mensajes en psock->cork, el último mensaje que activa el vaciado dará como resultado el envío de un sk_msg más grande que el tamaño del mensaje actual. En este caso, en tcp_bpf_send_verdict(), 'copied' se vuelve negativo al menos en el siguiente caso: 468 case __SK_DROP: 469 default: 470 sk_msg_free_partial(sk, msg, tosend); 471 sk_msg_apply_bytes(psock, tosend); 472 *copied -= (tosend + delta); // <==== HERE 473 return -EACCES; Por lo tanto, podría generar el siguiente ERROR con un valor adecuado de 'copied' (gracias a syzbot). No deberíamos usar 'copied' negativo como valor de retorno aquí. ------------[ corte aquí ]------------ ¡ERROR del kernel en net/socket.c:733! Error interno: Oops - BUG: 00000000f2000800 [#1] PREEMPT Módulos SMP vinculados en: CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 No contaminado 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0 Nombre del hardware: linux,dummy-virt (DT) pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : sock_sendmsg_nosec net/socket.c:733 [en línea] pc : sock_sendmsg_nosec net/socket.c:728 [en línea] pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745 lr : sock_sendmsg_nosec net/socket.c:730 [en línea] lr : __sock_sendmsg+0x54/0x60 net/socket.c:745 sp : ffff800088ea3b30 x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000 x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000 x23: f9f0000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90 x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001 x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0 x8 : 0000000000000000 x7 : 0000000000000003f x6 : 0000000000000000 x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900 x2 : 000000000000000 x1 : 000000000000000 x0 : 00000000fffffdef Rastreo de llamadas: sock_sendmsg_nosec net/socket.c:733 [en línea] __sock_sendmsg+0x5c/0x60 net/socket.c:745 ____sys_sendmsg+0x274/0x2ac net/socket.c:2597 ___sys_sendmsg+0xac/0x100 net/socket.c:2651 __sys_sendmsg+0x84/0xe0 net/socket.c:2680 __do_sys_sendmsg net/socket.c:2689 [en línea] __se_sys_sendmsg net/socket.c:2687 [en línea] __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687 __invoke_syscall arch/arm64/kernel/syscall.c:35 [en línea] anybody_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49 el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151 el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598 Código: f9404463 d63f0060 3108441f 54fffe81 (d4210000) ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mana: Se corrige el manejo de errores en la limpieza de NAPI de mana_create_txq/rxq Actualmente, napi_disable() se llama durante la limpieza de rxq y txq, incluso antes de que napi esté habilitado y hrtimer se inicialice. Provoca pánico del kernel. ? page_fault_oops+0x136/0x2b0 ? page_counter_cancel+0x2e/0x80 ? do_user_addr_fault+0x2f2/0x640 ? refill_obj_stock+0xc4/0x110 ? exc_page_fault+0x71/0x160 ? asm_exc_page_fault+0x27/0x30 ? __mmdrop+0x10/0x180 ? __mmdrop+0xec/0x180 ? hrtimer_active+0xd/0x50 hrtimer_try_to_cancel+0x2c/0xf0 hrtimer_cancel+0x15/0x30 napi_disable+0x65/0x90 mana_destroy_rxq+0x4c/0x2f0 mana_create_rxq.isra.0+0x56c/0x6d0 ? mana_uncfg_vport+0x50/0x50 mana_alloc_queues+0x21b/0x320 ? skb_dequeue+0x5f/0x80

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fscache: eliminar fscache_cookie_lru_timer cuando fscache sale para evitar UAF fscache_cookie_lru_timer se inicializa cuando se inserta el módulo fscache, pero no se elimina cuando se elimina el módulo fscache. Si se llama a timer_reduce() antes de eliminar el módulo fscache, fscache_cookie_lru_timer se agregará a la lista de temporizadores de la CPU actual. Posteriormente, se activará un use after free en el softIRQ después de quitar el módulo fscache, de la siguiente manera: ======================================================================== ERROR: no se puede manejar el error de página para la dirección: fffffbfff803c9e9 PF: acceso de lectura del supervisor en modo kernel PF: error_code(0x0000) - página no presente PGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Contaminado: GW 6.11.0-rc3 #855 Contaminado: [W]=ADVERTENCIA RIP: 0010:__run_timer_base.part.0+0x254/0x8a0 Rastreo de llamadas: tmigr_handle_remote_up+0x627/0x810 __walk_groups.isra.0+0x47/0x140 tmigr_handle_remote+0x1fa/0x2f0 handle_softirqs+0x180/0x590 irq_exit_rcu+0x84/0xb0 sysvec_apic_timer_interrupt+0x6e/0x90 asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:default_idle+0xf/0x20 default_idle_call+0x38/0x60 do_idle+0x2b5/0x300 cpu_startup_entry+0x54/0x60 start_secondary+0x20d/0x280 common_startup_64+0x13e/0x148 Módulos vinculados en: [última descarga: netfs] ======================================================================= Por lo tanto, elimine fscache_cookie_lru_timer al eliminar el módulo fscahe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: eliminar tst_run de lwt_seg6local_prog_ops. El syzbot informó que las operaciones BPF relacionadas con lwt_seg6 se pueden invocar mediante bpf_test_run() sin ingresar primero input_action_end_bpf(). Martin KaFai Lau dijo que la autoprueba para BPF_PROG_TYPE_LWT_SEG6LOCAL probablemente no funcionó ya que se introdujo en el commit 04d4b274e2a ("ipv6: sr: Agregar acción seg6local End.BPF"). La razón es que la variable por CPU seg6_bpf_srh_states::srh nunca se asigna en el caso de la autoprueba, pero cada función BPF lo espera. Eliminar test_run para BPF_PROG_TYPE_LWT_SEG6LOCAL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (w83627ehf) Se corrigen los desbordamientos de línea observados al escribir los atributos de límite DIV_ROUND_CLOSEST() después de que kstrtol() dé como resultado un desbordamiento de línea si el usuario proporciona un número negativo grande, como -9223372036854775808. Se soluciona reordenando las operaciones clamp_val() y DIV_ROUND_CLOSEST().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (nct6775-core) Se corrigen los desbordamientos de línea observados al escribir los atributos de límite DIV_ROUND_CLOSEST() después de que kstrtol() genere un desbordamiento de línea si el usuario proporciona un número negativo grande, como -9223372036854775808. Se soluciona reordenando las operaciones clamp_val() y DIV_ROUND_CLOSEST().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (lm95234) Se corrigen los desbordamientos de línea observados al escribir los atributos de límite DIV_ROUND_CLOSEST() después de que kstrtol() genere un desbordamiento de línea si el usuario proporciona un número negativo grande, como -9223372036854775808. Se soluciona reordenando las operaciones clamp_val() y DIV_ROUND_CLOSEST().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw88: usb: programar el trabajo de rx después de que todo esté configurado En este momento, es posible alcanzar la desreferencia del puntero NULL en rtw_rx_fill_rx_status en el objeto hw y/o sus campos porque la rutina de inicialización puede comenzar a recibir respuestas USB antes de que rtw_dev esté completamente configurado. El seguimiento de la pila se ve así: rtw_rx_fill_rx_status rtw8821c_query_rx_desc rtw_usb_rx_handler ... queue_work rtw_usb_read_port_complete ... usb_submit_urb rtw_usb_rx_resubmit rtw_usb_init_rx rtw_usb_probe Entonces, mientras hacemos las cosas asincrónicas, rtw_usb_probe continúa y llama a rtw_register_hw, que realiza todo tipo de inicialización (por ejemplo, a través de ieee80211_register_hw) de la que depende rtw_rx_fill_rx_status. Arregle esto moviendo el primer usb_submit_urb después de que todo esté configurado. Para mí, este error se manifestó como: [8.893177] rtw_8821cu 1-1:1.2: banda incorrecta, paquete descartado [8.910904] rtw_8821cu 1-1:1.2: hw->conf.chandef.chan NULL en rtw_rx_fill_rx_status porque estoy usando el backport de Larry del controlador rtw88 con las comprobaciones NULL en rtw_rx_fill_rx_status.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen: privcmd: Fix possible access to a freed kirqfd instance Nada impide llamadas ioctl simultáneas a privcmd_irqfd_assign() y privcmd_irqfd_deassign(). Si eso sucede, es posible que un kirqfd creado y agregado a la irqfds_list por privcmd_irqfd_assign() pueda ser eliminado por otro hilo que ejecuta privcmd_irqfd_deassign(), mientras que el primero todavía lo está usando después de eliminar los bloqueos. Esto puede llevar a una situación en la que se puede acceder a una instancia kirqfd ya liberada y causar errores del kernel. Use el bloqueo SRCU para evitar lo mismo, como se hace para la implementación de KVM para irqfds.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: añadir comprobación de nombre no válido en btf_name_valid_section() Si la longitud de la cadena de nombre es 1 y el valor de name[0] es un byte NULL, se produce una vulnerabilidad OOB en btf_name_valid_section() y el valor de retorno es verdadero, por lo que el nombre no válido pasa la comprobación. Para resolver esto, debe comprobar si la primera posición es un byte NULL y si el primer carácter es imprimible.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: proteger la configuración de XDP con un mutex La principal amenaza a la consistencia de los datos en ice_xdp() es un posible reinicio asincrónico de PF. Puede ser activado por un usuario o por el controlador de tiempo de espera de TX. El código de configuración de XDP y de restablecimiento de PF accede a los mismos recursos en las siguientes secciones: * ice_vsi_close() en ice_prepare_for_reset() - ya bloqueado en RTNL * ice_vsi_rebuild() para PF VSI - no protegido * ice_vsi_open() - ya bloqueado en RTNL Con un momento desafortunado, dichos accesos pueden resultar en un bloqueo como el siguiente: [ +1.999878] ice 0000:b1:00.0: Modelo de memoria XDP registrado MEM_TYPE_XSK_BUFF_POOL en el anillo Rx 14 [ +2.002992] ice 0000:b1:00.0: Modelo de memoria XDP registrado MEM_TYPE_XSK_BUFF_POOL en el anillo Rx 18 [15 de marzo 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: la cola de transmisión 14 agotó el tiempo de espera 80692736 ms [ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001 [ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout nivel de recuperación 1, txqueue 14 [ +0.394718] ice 0000:b1:00.0: restablecimiento de PTP exitoso [ +0.006184] ERROR: puntero NULL del núcleo desreferencia, dirección: 0000000000000098 [ +0.000045] #PF: acceso de lectura de supervisor en modo kernel [ +0.000023] #PF: error_code(0x0000) - página no presente [ +0.000023] PGD 0 P4D 0 [ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI [ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 No contaminado 6.8.0-rc7 #1 [ +0.000031] Nombre del hardware: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 26/08/2021 [ +0.000036] Cola de trabajo: hielo ice_service_task [hielo] [ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [hielo] [...] [ +0.000013] Rastreo de llamadas: [ +0.000016] [ +0.000014] ? __die+0x1f/0x70 [ +0.000029] ? page_fault_oops+0x171/0x4f0 [ +0.000029] ? schedule+0x3b/0xd0 [ +0.000027] ? exc_page_fault+0x7b/0x180 [ +0.000022] ? asm_exc_page_fault+0x22/0x30 [ +0.000031] ? hielo_limpio_tx_ring+0xa/0xd0 [hielo] [ +0.000194] hielo_libre_tx_ring+0xe/0x60 [hielo] [ +0.000186] hielo_destruir_xdp_rings+0x157/0x310 [hielo] [ +0.000151] hielo_vsi_decfg+0x53/0xe0 [hielo] [ +0.000180] hielo_vsi_rebuild+0x239/0x540 [hielo] [ +0.000186] hielo_vsi_rebuild_by_type+0x76/0x180 [hielo] [ +0.000145] hielo_rebuild+0x18c/0x840 [hielo] [ +0.000145] ? retraso_tsc+0x4a/0xc0 [ +0.000022] ? retraso_tsc+0x92/0xc0 [ +0.000020] hielo_do_reset+0x140/0x180 [hielo] [ +0.000886] hielo_servicio_tarea+0x404/0x1030 [hielo] [ +0.000824] proceso_una_obra+0x171/0x340 [ +0.000685] subproceso_trabajador+0x277/0x3a0 [ +0.000675] ? preempt_count_add+0x6a/0xa0 [ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50 [ +0.000679] ? La forma anterior de manejar esto mediante la devolución de -EBUSY no es viable, particularmente cuando se destruye el socket AF_XDP, porque el núcleo procede con la eliminación de todos modos. Hay mucho código entre esas llamadas y no hay necesidad de crear una gran sección crítica que las cubra todas, al igual que no hay necesidad de proteger ice_vsi_rebuild() con rtnl_lock(). Agregue el mutex xdp_state_lock para proteger ice_vsi_rebuild() y ice_xdp(). Dejar secciones desprotegidas en el medio daría como resultado dos estados que deben considerarse: 1. cuando el VSI está cerrado, pero aún no se reconstruye 2. cuando VSI ya se está reconstruyendo, pero aún no está abierto El último caso en realidad ya se maneja a través del caso !netif_running(), solo necesitamos ajustar un poco la verificación de indicadores. El primero no es tan trivial, porque entre ice_vsi_close() y ice_vsi_rebuild(), ocurre mucha interacción de hardware, esto puede hacer que agregar/eliminar anillos salga con un error. Afortunadamente, la reconstrucción de VSI está pendiente y puede aplicar una nueva configuración para nosotros de manera administrada. ---truncado---